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Government  and  industry  have  the  need  to  improve  the  maturity  of  their  internal  software 
acquisition  processes.  In  order  for  organizations  to  make  improvements,  they  must  know 
the  ultimate  goal  and  what  is  required  to  achieve  that  goal.  Additionally,  progress  toward 
achieving  the  goal  must  be  measurable.  A  capability  maturity  model  provides  the 
framework  needed  to  facilitate  the  desired  improvement.  The  Software  Acquisition 
Capability  Maturity  Model  (SA-CMM)  has  been  developed  to  provide  such  a  framework. 

This  new  version  incorporates  change  requests  that  have  been  received,  as  well  as  the 
results  of  lessons  learned  from  conducting  appraisals  and  from  the  use  of  Version  1.01. 
Constructive  comments,  using  the  form  at  the  end  of  this  document,  resulting  from  the 
use  of  Version  1.02  of  the  SA-CMM  are  not  only  welcome  but  are  encouraged. 

The  Context  of  the  SA-CMM 

The  experience  of  the  Software  Engineering  Institute  in  developing  the  Capability 
Maturity  Model  for  Software  (SW-CMM)  was  directly  applicable  to  developing  the  SA- 
CMM.  The  SW-CMM  describes  the  developer’s  (contractor’s)  role  while  the  SA-CMM 
describes  the  buyer’s  (acquirer’s)  role  in  the  software  acquisition  process.  In  the  SA- 
CMM  an  individual  software  acquisition  begins  with  the  process  of  defining  a  system 
need.  Some  activities  performed  by  the  acquisition  organization  may  pre-date  the 
establishment  of  a  project  office.  The  SA-CMM  includes  certain  pre-contract  award 
activities,  such  as  preparing  the  solicitation  package,  developing  the  initial  set  of 
requirements,  and  participating  in  source  selection.  During  the  engineering  phase  of  the 
project,  the  two  models  are  parallel  in  their  treatment  of  the  processes  involved.  In  the 
SA-CMM  an  individual  software  acquisition  ends  when  the  contract  for  software 
products  and  services  is  concluded. 

Although  the  SA-CMM  is  logically  consistent  with  the  SW-CMM,  it  is  not  a  mirror 
image  of  the  SW-CMM.  The  SW-CMM  addresses  software  engineering  (development) 
functions  while  the  SA-CMM  addresses  the  functions  that  support  the  acquisition  of 
software.  These  are  two  different  processes  with  different  goals  and  different  activities. 
Consequently,  the  groupings  (key  process  areas)  of  the  SA-CMM  are  different.  That 
difference  does  not  mean  the  two  models  are  incompatible.  They  do  have  the  same 
architecture,  design,  format,  and  appraisal  methodology,  as  well  as  other  similarities.  The 
two  models  can  be  used  in  parallel  on  the  same  project  since  they  address  the  same 
requirements,  proceed  on  the  same  schedule,  and  pursue  the  same  objective — high  quality 
deliverables.  The  two  models  are  synergistic. 

The  SA-CMM  identifies  key  process  areas  for  four  of  its  five  levels  of  maturity.  The  key 
process  areas  state  the  goals  that  must  be  satisfied  to  achieve  each  level  of  maturity.  In 
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other  words,  progress  is  made  in  stages  or  steps.  The  levels  of  maturity  and  their  key 
process  areas  thus  provide  a  roadmap  for  achieving  higher  levels  of  maturity. 

Typically,  a  portion  of  the  goals  or  activities  of  some  higher  level  key  process  areas  are 
satisfied/performed  at  a  lower  level.  However,  a  key  process  area  cannot  be  achieved 
until  all  of  its  goals  have  been  satisfied.  A  maturity  level  is  achieved  by  mastering  all  of 
its  key  process  areas.  Once  a  maturity  level  is  achieved,  the  model  requires  that  the 
satisfaction  of  all  lower  level  goals  is  maintained. 

The  stages  of  the  model  are  complementary  and  flow  upward.  For  example,  at  Level  2 
some  of  the  activities  of  Contract  Tracking  and  Oversight  will  result  in  corrective  actions 
(a  reactive  approach  to  deficiencies).  This  process  grows  and  matures;  in  Level  3  the 
activities  of  Contract  Performance  Management  are  performed  to  identify  and  prepare  for 
deficiencies  before  they  occur  (a  proactive  approach).  Contract  Performance 
Management  grows  and  matures  to  become  Quantitative  Acquisition  Management  at 
Level  4  when  the  process(es)  is  adjusted  based  on  quantitative  data  (quantitative 
approach).  At  Level  5,  Continuous  Process  Improvement  uses  quantitative  data  to 
optimize  process  performance  (optimizing  approach). 

Just  as  the  stages  of  a  capability  maturity  model  flow  upward,  the  satisfaction  of  goals 
must  be  maintained  as  an  organization  moves  up  the  levels  of  maturity  .The  SA-CMM 
contains  a  similar  thread;  activities  or  events  that  occur  at  a  lower  level  are  not  required  to 
be  re-instantiated  at  higher  levels.  For  example,  a  group  is  established  for  managing  the 
contract  in  the  Contract  Tracking  and  Oversight  key  process  area  at  Level  2,  the  SA- 
CMM  assumes  that  the  same  group  is  still  in  place  when  the  organization  moves  to  Level 
3.  Thus,  there  is  no  requirement  in  the  Contract  Performance  Management  key  process 
area  at  Level  3  to  re-establish  a  contract  management  group.  This  approach  reduces 
unnecessary  redundancy  in  subsequent  key  process  areas  and  makes  implementation  more 
efficient. 

The  SA-CMM  is  designed  to  be  generic  enough  for  use  by  any  government  or  industry 
organization,  regardless  of  size,  acquiring  software.  When  applying  the  SA-CMM  to  a 
particular  organization,  translations  may  need  to  be  made  (in  addition  to  tailoring  the 
model  to  fit  a  specific  acquisition).  The  SA-CMM  addresses  an  “organization”  which  is 
the  parent  of  the  “acquisition  organization.”  The  acquisition  organization  specializes  in 
acquisition  and  may  be  responsible  for  more  than  one  project.  The  project  team  is  the 
entity  that  has  the  responsibility  for  executing  the  specific  acquisition.  The  project  team 
is  supported  by  “other  (affected)  groups”  (functionals,  matrix,  etc.)  in  the  conduct  of  the 
acquisition.  In  the  SA-CMM,  the  terms  “group,”  “team,”  “office,”  and  similar  terms  may 
indicate  situations  where  the  specific  implementation  may  vary  from  a  single  individual 
assigned  part-time,  to  several  part-time  individuals  assigned  from  other  organizations,  to 
several  individuals  dedicated  full-time.  The  structure  of  the  model  must  be  mapped  onto 
the  particular  situation  where  the  model  is  being  applied.  Also,  the  terminology  of  the 
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model  has  been  made  as  generic  as  possible  and  must  be  mapped  onto  the  local  situation; 
some  examples  are  “contracting  official,”  “affected  groups,”  and  “domain.” 

The  S  A-CMM  should  be  interpreted  in  the  context  of  the  needs  of  the  organization;  just 
because  something  is  in  the  S A-CMM  does  not  mean  it  should  be  applied  automatically. 
Effective  and  efficient  software  acquisition  processes  are  critical  to  successful  process 
improvement,  but  the  quality  of  their  output  can  only  be  determined  in  the  context  of  the 
business  needs  of  the  organization. 

Use  of  the  SA-CMM  is  not  limited  to  situations  where  software  is  being  acquired  under 
formal  contract.  It  can  be  used  by  any  organization  acquiring  software  or  software-related 
services.  For  this  usage,  the  term  “contractor”  refers  to  the  organization  performing  the 
software  engineering  effort.  The  term  “project  team”  refers  to  the  individuals  within  the 
acquiring  organization  who  have  an  assigned  software  acquisition  responsibility,  and  the 
term  “contract”  refers  to  the  agreement  between  the  organizations. 

The  SA-CMM  applies  to  the  acquisition  of  all  types  of  embedded  and  stand-alone 
software  applications,  including  those  where  commercial-off-the-shelf  (COTS)  and  non- 
developmental  item  (NDI)  software  are  being  acquired,  either  as  a  part  of  a  system  or 
separately.  Naturally,  the  model  may  have  to  be  tailored  to  fit  the  specific  circumstances. 

The  SA-CMM  is  appropriate  for  use  throughout  the  entire  software  life  cycle.  During  the 
life  cycle  of  a  system,  many  individual  acquisitions  can  occur;  an  acquisition  can  occur  in 
the  system’s  operational  and  support  phase  as  well  as  for  its  initial  development.  In  cases 
where  products  and  services  for  enhancing  or  reengineering  the  software  are  being 
acquired,  the  software  support  organization  takes  on  the  role  of  the  acquirer.  Thus,  the 
model  is  applicable. 

The  SA-CMM  accommodates  the  software  that  is  acquired  as  a  part  of  a  total  system 
acquisition.  It  does  not  specifically  address  the  “system  acquisition”  process;  however,  it 
is  in  harmony  with  and  references  that  process. 

Every  acquisition  project  germinates  with  a  requirement,  albeit  at  a  very  high  level.  As 
the  acquisition  begins  to  form,  more  requirements  are  identified  and  refined.  This 
evolution  proceeds  and  the  set  of  requirements  continues  to  grow.  By  the  time  the 
solicitation  package  is  developed,  a  significant  set  of  software  technical  and  non-technical 
requirements  exists.  For  purposes  of  the  SA-CMM,  these  requirements  must  be  baselined 
(managed  and  controlled),  not  frozen.  As  software  requirements  further  evolve  (e.g., 
allocation,  elaboration,  and  refinement),  they  are  incorporated  into  the  requirements 
baseline,  and  managed  and  controlled.  Management  and  control  of  the  software 
requirements  remain  the  acquirer’s  responsibility  even  though  the  contractor  team  may  be 
involved  in  the  requirements  development  process. 
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A  project  should  have  established  baselines  for  the  software’s  performance  (technical) 
requirements,  for  the  cost  of  the  software  being  acquired,  and  for  the  schedule  of  the 
acquisition  project.  The  SA-CMM  recognizes  that,  historically,  project  managers  may 
not  have  had  the  latitude  to  make  trade-offs  in  these  parameters  to  optimize  the  project. 
Consequently,  the  model  recognizes  the  necessity  of  giving  the  project  manager  the 
flexibility  to  adjust  one  of  these  baselines  for  control  and  use  in  making  trade-offs, 
thereby  enhancing  the  probability  for  a  successful  acquisition. 

The  SA-CMM  is  based  on  the  expectation  that  a  mature  organization  and  its  projects  will 
do  a  thorough  job  of  planning  an  acquisition.  The  Software  Acquisition  Planning  key 
process  area  addresses  the  planning  process  that  must  take  place  as  an  adjunct  to 
managing  the  software  acquisition  project.  Each  of  the  remaining  key  process  areas 
addresses  a  planning  process  as  one  of  the  area’s  activities.  How  to  document  this 
planning  is  the  option  of  the  acquisition  organization  and  the  project  team.  While  other 
planning  documents  may  be  created  for  the  project,  the  SA-CMM  does  identify  two 
specific  plans  -  the  Project  Management  Plan  and  the  Software  Acquisition  Risk 
Management  Plan.  The  method  of  documenting  these  two  specific  plans  is  also  the 
option  of  the  acquisition  organization  and  the  project  team.  The  resulting  project 
planning  documentation  need  not  be  any  more  extensive  than  that  of  any  well-managed 
software  acquisition  project. 

The  Architecture  of  the  SA-CMM 


Figure  1.  SA-CMM  Architecture 
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The  SA-CMM  defines  five  levels  of  maturity.  Each  maturity  level  (except  Level  1) 
indicates  process  capability  and  contains  key  process  areas.  Key  process  areas  contain 
goals  and  five  common  features.  The  common  features  are  attributes  that  indicate  if  the 
implementation  and  institutionalization  of  a  key  process  area  can  be  effective,  repeatable, 
and  lasting.  Figure  1  depicts  the  architecture  of  the  SA-CMM  and  Figure  2  provides  a 
synopsis  of  its  content.  The  goals  and  five  common  features  are  described  below: 

Goals.  Goals  are  the  aggregate  result  achieved  by  the  effective  implementation  of  the 
common  features  of  a  key  process  area. 

Commitment  to  perform.  Commitment  to  perform  describes  the  actions  that  the 
organization  must  take  to  establish  the  process  and  ensure  that  it  can  endure. 
Commitment  to  perform  typically  involves  establishing  organizational  policies  and 
management  sponsorship. 

Ability  to  perform.  Ability  to  perform  describes  the  preconditions  that  must  exist  in  the 
project  or  organization  to  implement  the  software  acquisition  process  competently. 
Ability  to  perform  typically  involves  resources,  organizational  structures,  and  training. 

Activities  performed.  Activities  performed  describes  the  roles  and  procedures  necessary 
to  implement  a  key  process  area.  Activities  performed  typically  involves  establishing 
plans  and  procedures,  performing  the  work,  tracking  it,  and  taking  appropriate 
management  actions. 

Measurement  and  analysis.  Measurement  and  analysis  describes  the  need  to  measure 
the  process  and  analyze  the  measurements.  Measurement  and  analysis  typically  includes 
examples  of  the  measurements  that  could  be  taken  to  determine  the  status  and 
effectiveness  of  the  activities  performed. 

Verifying  implementation.  Verifying  implementation  describes  the  steps  to  ensure  that 
the  activities  are  performed  in  compliance  with  the  process  that  has  been  established. 
Verifying  implementation  typically  encompasses  reviews  by  management. 

The  Maturity  Levels  of  the  SA-CMM 

The  acquisition  organization  management  must  increase  its  involvement,  leadership,  and 
discipline  as  it  attempts  to  achieve  each  higher  level  of  maturity.  The  maturity  levels 
provide  a  roadmap  for  the  continuous  improvement  of  an  organization’s  software 
acquisition  process,  they  are  not  intended  to  serve  as  a  rating  mechanism.  The  following 
describes  the  five  maturity  levels  of  the  SA-CMM,  highlighting  the  primary  process 
improvements  made  at  each  level. 
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Figure  2.  Synopsis  of  the  SA-CMM 


1)  Initial  -  The  software  acquisition  process  is  characterized  as  ad  hoc,  and  occasionally 
even  chaotic.  Few  processes  are  defined  and  success  depends  on  individual  effort.  For 
an  organization  to  mature  beyond  the  initial  level,  it  must  install  basic  management 
controls  to  instill  self-discipline. 

2)  Repeatable  -  Basic  software  acquisition  project  management  processes  are  established 
to  plan  all  aspects  of  the  acquisition,  manage  software  requirements,  track  project  team 
and  contractor  team  performance,  manage  the  project’s  cost  and  schedule  baselines, 
evaluate  the  products  and  services,  and  successfully  transition  the  software  to  its  support 
organization.  The  project  team  is  basically  reacting  to  circumstances  of  the  acquisition  as 
they  arise.  The  necessary  process  discipline  is  in  place  to  repeat  earlier  successes  on 
projects  in  similar  domains.  For  an  organization  to  mature  beyond  the  level  of  self- 
discipline,  it  must  use  well-defined  processes  as  a  foundation  for  improvement. 


3)  Defined  -  The  acquisition  organization’s  software  acquisition  process  is  documented 
and  standardized.  All  projects  use  an  approved,  tailored  version  of  the  organization’s 
standard  software  acquisition  process  for  acquiring  their  software  products  and  services. 
Project  and  contract  management  activities  are  proactive,  attempting  to  anticipate  and 
deal  with  acquisition  circumstances  before  they  arise.  Risk  management  is  integrated 
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into  all  aspects  of  the  project,  and  the  organization  provides  the  training  required  by 
personnel  involved  in  the  acquisition.  For  an  organization  to  mature  beyond  the  level  of 
defined  processes,  it  must  base  decisions  on  quantitative  measures  of  its  processes  and 
products  so  that  objectivity  can  be  attained  and  rational  decisions  made. 

4)  Quantitative  -  Detailed  measures  of  the  software  acquisition  processes,  products,  and 
services  are  collected.  The  software  processes,  products,  and  services  are  quantitatively 
and  qualitatively  understood  and  controlled. 

5)  Optimizing  -  Continuous  process  improvement  is  empowered  by  quantitative  feedback 
from  the  process  and  from  piloting  innovative  ideas  and  technologies.  Ultimately  an 
organization  recognizes  that  continual  improvement  (and  continual  change)  is  necessary 
to  survive. 

Principles  Governing  the  Interpretation  of  the  SA-CMM 

Generic  Model.  The  SA-CMM  is  a  generic  model  for  broad  usage.  In  a  specific  context, 
implementation  and  improvement  needs  may  vary. 

Organizational  Improvement.  The  SA-CMM  is  a  model  for  organizational  improvement. 
The  SA-CMM  focuses  on  building  the  process  capability  of  an  organization. 

Improvement  Roadmap.  The  activities  of  the  SA-CMM  describe  the  characteristics  of  a 
software  acquisition  process  that  one  would  normally  expect  to  see  at  each  maturity  level. 
The  SA-CMM  does  not  prescribe  how  an  organization  is  to  improve  its  processes;  it 
describes  the  attributes  of  an  organization’s  process  maturity  at  five  levels  of  maturity. 
The  maturity  levels  prescribe  an  ordering  of  how  to  prioritize  process  improvement 
actions. 

Key  Process  Areas.  The  SA-CMM  describes  key  process  areas  and  activities;  it  is  not 
exhaustive,  and  additional  process  areas  may  be  appropriate  for  an  organization. 

Comprehensiveness.  The  SA-CMM  does  not  address  all  the  factors  that  impact  software 
acquisition.  Examples  of  excluded  topics  are  systems  engineering  and  human  resources. 

Process  Management.  The  quality  of  a  software  product  or  service  is  largely  governed  by 
the  quality  of  the  software  processes  used  to  develop,  acquire,  or  maintain  it. 

Process  Improvement.  Any  process  can  be  improved;  continuous  improvement  is 
necessary  to  increase  efficiency  and  maintain  competitiveness  in  a  changing  environment. 

No  One  Right  Way.  There  is  not  “one  right  way”  to  implement  a  software  acquisition 
process.  The  SA-CMM  is  not  engraved  in  stone.  Also,  except  in  a  few  carefully  chosen 
instances,  the  SA-CMM  does  not  mandate  how  the  software  acquisition  process  should 
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be  implemented  or  who  should  perform  an  action;  it  describes  what  characteristics  the 
software  acquisition  process  should  possess. 

Technology.  The  SA-CMM  is  technology  independent.  No  specific  tools,  methods,  or 
technologies  are  mandated  by  the  SA-CMM.  Appropriate  tools,  methods,  and 
technologies  should  be  made  available  to  support  the  process. 

Professional  Judgement.  Professional  judgement  must  be  applied  when  interpreting,  for 
a  particular  organization,  the  activities  of  the  SA-CMM.  The  SA-CMM  should  be 
tailored  to  fit  the  organization;  the  organization  should  not  be  restructured  to  reflect  the 
SA-CMM. 


The  Competence  Principle.  The  competence  of  the  people  doing  the  work  is  a  major 
factor  in  project  performance  and  organizational  success.  (Competence  includes 
knowledge  of  the  application  domain,  software  acquisition  methods,  and  quantitative 
methods,  and  having  interpersonal  and  problem  solving  skills.) 
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At  the  Initial  Level,  the  project  team  typically  does  not  provide  a  stable  environment  for 
acquiring  software.  The  project  team  is  staffed  based  on  the  availability  of  individuals,  resulting 
in  a  random  composition  of  acquisition  skills.  Software  acquisition  does  not  receive  adequate 
management  visibility.  The  project  is  pursued  in  an  ad  hoc  manner. 

There  are  no  key  process  areas  at  Level  1. 


CMU/SEI-99-TR-002 


Ll-1 


Level  1:  The  Initial  Level 


Level  2  -  The  Repeatable  Level 


At  the  Repeatable  Level,  the  project  team  is  knowledgeable  and  supportive  of  promulgated 
policies,  regulations,  and  standards  that  relate  to  its  project  and  makes  a  dedicated  attempt  to 
comply  with  them.  Software  acquisition  management  plans  and  procedures  are  established  by 
the  project  team.  The  planning  and  tracking  of  new  projects  are  based  on  experience  with  similar 
projects.  An  objective  in  achieving  Level  2  is  to  stabilize  both  the  software  contract  management 
and  project  management  processes,  allowing  project  teams  to  repeat  successful  practices 
employed  on  earlier  projects. 

Level  2  project  teams  have  instituted  basic  software  acquisition  management  practices  and 
controls.  All  members  of  the  team  are  committed  to  complying  with  project  plans,  required 
policies,  regulations,  and  standards.  Project  managers  track  costs,  schedules,  requirements,  and 
performance  of  the  project.  Problems  in  meeting  commitments  are  identified  when  they  arise. 
Software  requirements  are  baselined  and  the  content  is  controlled.  Software  documentation  is 
evaluated  for  compliance  with  specified  requirements.  Project  teams  work  with  their  prime 
contractors,  and  any  subcontractors,  to  establish  a  stable,  cooperative  working  environment. 
Project  teams  track  the  performance  of  the  contractor  team  for  adherence  with  project  plans  and 
for  ensuring  that  contractual  requirements  are  being  satisfied. 

The  process  capability  of  Level  2  acquisition  organizations  can  be  summarized  as  being  stable 
for  planning  and  tracking  the  software  acquisition  because  documented  procedures  provide  a 
project  environment  for  repeating  earlier  successes. 

Level  2  key  process  areas  are: 

Software  Acquisition  Planning 
Solicitation 

Requirements  Development  and  Management 

Project  Management 

Contract  Tracking  and  Oversight 

Evaluation 

Transition  to  Support 
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Software  Acquisition  Planning 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Software  Acquisition  Planning  is  to  ensure  that  reasonable  planning  for  the 
software  acquisition  is  conducted  and  that  all  elements  of  the  project  are  included. 

Software  Acquisition  Planning  involves  the  preparation  for  software-related  areas  in  system  level 
planning  such  as  early  budgetary  action,  schedule  determination,  acquisition  strategy,  risk 
identification,  and  software  requirements  definition.  There  are  other  traditional  software 
acquisition  planning  activities  that  must  be  performed  in  the  context  of  the  system  as  a  whole  and 
in  coordination  with  the  project  team  (e.g.,  system  requirements  development,  hardware/software 
partitioning,  system  level  software  requirements  allocation,  and  solicitation  management). 
Software  Acquisition  Planning  also  involves  planning  all  aspects  of  the  software  acquisition 
project.  Software  acquisition  planning  documentation  provides  for  implementation  of  all 
software  acquisition-related  policies. 

Software  acquisition  planning  begins  with  the  earliest  identification  of  a  role  for  software  in  the 
system  to  be  acquired.  The  process  starts  when  reasonable  resources  are  assigned  to  form  a 
project  team  for  the  acquisition,  independent  of  whether  or  not  the  team  is  formally  constituted  as 
an  organizational  entity.  Software  acquisition  planning  provides  for  conducting  and 
documenting  software  acquisition  planning  activities  and  participation  in  system  level  planning 
activities  as  appropriate. 

Goals 


Goal  1 

Goal  2 


Software  acquisition  planning  documents  are  prepared  during  system 
acquisition  planning  and  maintained  throughout  the  acquisition. 

Software  acquisition  planning  addresses  the  project’s  entire  software 
acquisition  process  and  life  cycle  support. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  planning  the 
software  acquisition. 

This  policy  typically  specifies  that: 

1 .  The  implementation  of  all  software  acquisition-related  policies  is  provided  for  in  the 
plans. 
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Software  Acquisition  Planning 


Commitment  2 


Ability  1 
Ability  2 


Ability  3 


Activity  1 


2.  The  plans  address  all  software-related  areas  of  the  acquisition. 


Some  examples  of  software-related  areas  include: 

software  acquisition  planning, 
project  management, 
solicitation, 

requirements  development  and  management, 
contract  management, 
evaluation,  and 

acquisition  risk  management. _ . 


3.  A  review  process  is  established  for  resolving  issues,  facilitating  acquisition  decisions,  and 
focusing  on  critical  issues  such  as  affordability  and  risk. 

4.  Responsibility  and  accountability  are  clearly  established  for  the  project. 

5.  Software  acquisition  planning  documentation  is  prepared  prior  to  solicitation  activities. 

6.  Software  acquisition  planning  documentation  is  maintained  current. 

7.  Software  acquisition  strategy  is  included  in  the  plans. 

Responsibility  for  software  acquisition  planning  activities  is  designated. 

Ability  to  perform 


A  group  that  is  responsible  for  planning  the  software  acquisition  exists. 

The  acquisition  organization  provides  experienced  software  acquisition 
management  personnel  to  support  project  software  acquisition  planning. 


Experience  means,  for  example,  having  participated  in  software  acquisition 
management  planning  on  at  least  one  project,  having  a  minimum  of  five  years 
acquisition  experience,  having  knowledge  of  the  software’s  application  domain,  and 
having  knowledge  of  current  software  engineering  processes  and  technology. _ 


Adequate  resources  are  provided  for  software  acquisition  planning 
activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Activities  performed 


Software  acquisition  planning  personnel  are  involved  in  system 
acquisition  planning. 
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Activity  2 
Activity  3 


Activity  4 


Activity  5 


The  project’s  software  acquisition  planning  is  accomplished  in 
conjunction  with  system  acquisition  planning. 

The  software  acquisition  strategy  for  the  project  is  developed  and 
documented. 

The  strategy  typically  includes  considerations  of: 

1.  The  objectives  of  the  acquisition. 

2.  Project  constraints,  such  as  funding  and  schedules. 

3.  Available  and  projected  assets  and  technologies,  such  as  reuse,  NDI,  and  COTS. 

4.  Software  acquisition  methods. 

5.  Potential  contract  types  and  terms. 

6.  End  user  considerations. 

7.  Consistency  with  the  system  acquisition  strategy. 

8.  Risk  identification. 

9.  Life  cycle  support  installation  approach. 

Software  acquisition  planning  addresses  the  elements  of  the  software 
acquisition  process. 


Some  examples  of  software-related  areas  include: 

software  risk  identification  and  tracking, 

project  management, 

solicitation, 

cost  and  schedule, 

requirements  development  and  management, 
contract  tracking  and  oversight, 
evaluation,  and 

transition  to  support. _ 

The  project’s  software  acquisition  planning  is  documented  and  the 
planning  documentation  is  maintained  over  the  life  of  the  project. 


Planning  documentation  may  be  in  a  single  document  or  in  separate  documents 
depending  on  the  specific  needs  of  the  project. _ 


Software  acquisition  planning  documentation  typically  includes: 
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Activity  6 


Activity  7 


Measurement  1 


1.  All  relevant  policy  for  the  software-related  areas  of  the  acquisition. 

2.  The  tasks  to  be  performed. 

3.  The  required  software  acquisition  resources. 

►  Resources  include  funding,  staff,  equipment,  and  tools. 

4.  The  roles  and  responsibilities  of  the  groups  involved  in  the  project. 

Typically  roles  and  responsibilities  include: 

end  user  representation  and  involvement  in  the  software  acquisition, 
interface  with  system-level  activities,  and 

project  team’s  relationship  with  and  responsibilities  to  the  acquisition  organization. _ 

5.  The  project’s  strategic  objectives. 

6.  A  master  schedule  of  software  acquisition  milestones. 

7.  Measurements  to  determine  the  progress  of  the  software  acquisition. 

Life  cycle  support  of  the  software  is  included  in  software  acquisition 
planning  documentation. 

Life  cycle  support  provisions  typically  include: 

1.  Identifying  adequate  facilities  and  resources  for  the  software  support  organization. 

2.  Providing  for  transitioning  the  software  from  acquisition  to  operation  and  to  the  software 
support  organization. 

3.  Providing  for  long-term  growth  and  supportability  of  the  system. 

Life  cycle  cost  and  schedule  estimates  for  the  software  products  and 
services  being  acquired  are  prepared  and  independently  reviewed. 

In  this  instance,  “independently  reviewed”  means  a  review  by  an  individual(s)  other  than 
the  author(s)  of  the  cost  and  schedule  estimates. _ 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  software 
acquisition  planning  activities  and  resultant  products. 


Some  examples  of  measurements  include: 
effort  expended; 
funds  expended; 

progress  towards  completion  of  software  acquisition  planning, 
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Verification  1 


Verification  2 


the  software  acquisition  strategy,  and  life  cycle  cost  estimates; 
and 

completion  of  milestones. _ 


Verifying  implementation 


Software  acquisition  planning  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  software  acquisition  planning  activities  at  an 
appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Software  acquisition  planning  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 


L2-6 


CMU/SEI-99-TR-002 


Level  2:  The  Repeatable  Level 


Solicitation 


Solicitation _ 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Solicitation  is  to  prepare  a  solicitation  package  that  identifies  the  needs  of  a 
particular  acquisition  and  to  select  a  contractor  who  is  best  capable  of  satisfying  the  requirements 
of  the  contract. 

Solicitation  involves  planning  and  performing  the  activities  necessary  to  issue  the  solicitation 
package,  preparing  for  the  evaluation  of  responses,  conducting  the  evaluation,  conducting 
supporting  negotiations,  and  making  recommendations  for  award  of  the  contract.  Solicitation 
ends  with  contract  award. 

Goals 


Goal  1  The  selection  official  selects  a  contractor  who  is  qualifi ed  to  satisfy  the 

contract’s  requirements  for  the  project’s  software-related  products  and 
services. 

Goal  2  Solicitation  activities  are  compliant  with  relevant  laws,  regulations, 

policies,  and  guidance. 

Goal  3  The  solicitation  package  includes  the  contractual  software  requirements 

and  proposal  evaluation  criteria. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  conduct  of  the 
software  portion  of  the  solicitation. 

This  policy  typically  specifies  that: 

1 .  Planning  for  solicitations  is  documented. 

2.  Planning  for  proposal  evaluation  activities  is  documented. 

3.  Solicitations  are  conducted  in  a  manner  compliant  with  applicable  laws,  regulations, 
policies,  and  guidance  for  the  solicitation. 

4  Solicitation  activities  are  tailored  based  on  the  cost  and/or  complexity  of  the  software 
item  or  service  being  acquired. 
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5.  The  contract  type  (e.g.,  fixed-price,  cost-reimbursement)  is  chosen  based  on  the  perceived 
risk  of  successfully  delivering  the  required  items  while  satisfying  the  cost  and  schedule 
requirements  of  the  contract. 

Normally,  the  less  the  risk  to  the  offeror,  the  more  rigid  the  contract  type.  For  example,  a  fixed-price 
contract  type  would  be  suitable  for  a  commodity  buy  while  a  cost-reimbursement  contract  type  is  more 
suitable  for  a  research  and  development  contract. _ 

6.  A  selection  official  is  designated  for  each  solicitation. 

Generally,  selection  officials  are  chosen  based  on  their  authority  to  commit  the  organization  to  a 
specified  dollar  amount  which  is  equal  to  or  greater  than  the  estimated  value  of  the  solicitation. _ 

7.  The  selection  official  for  a  solicitation  has  the  ultimate  responsibility  for  the  conduct  of 
the  solicitation  and  for  selecting  the  winning  offeror. 

Commitment  2  Responsibility  for  the  software  portion  of  the  solicitation  is  designated. 

Commitment  3  A  selection  official  has  been  designated  to  be  responsible  for  the  selection 
process  and  the  decision. 


Ability  to  perform 


Ability  1 


A  group  that  is  responsible  for  coordinating  and  conducting  solicitation 
activities  exists. 


Ability  2 


Adequate  resources  are  provided  for  solicitation  activities. 


Ability  3 


Resources  include  funding,  staff,  equipment,  and  tools. 

Individuals  performing  solicitation  activities  have  experience  or  receive 
training. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition 
management  role  on  at  least  one  project,  having  knowledge  in  the  domain  of  the 
application  being  acquired,  and  having  familiarity  of  current  software  engineering 
processes,  products,  technology,  and  costing  methodologies  and  tools.  Additionally, 
some  individuals  must  have  experience  in  conducting  solicitation  activities. 


Ability  4 


The  groups  supporting  the  solicitation  (e.g.,  end  user,  systems 
engineering,  software  support  organization,  and  application  domain 
experts)  receive  orientation  on  the  solicitation’s  objectives  and 
procedures. 
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Solicitation 


Activity  1 


Activities  performed 


The  project  team  perforins  its  activities  in  accordance  with  its 
documented  solicitation  plans. 

The  plans  typically  cover: 

1.  The  objectives  of  the  solicitation. 

2.  Identification  of  the  contents  of  the  solicitation  package  such  as: 

►  The  software  requirements. 

Refer  to  the  Requirements  Development  and  Management  key  process  area. 

►  The  proposal  evaluation  criteria. 

In  some  solicitations  a  determination  of  the  offeror’s  ability  to  perform  the  proposed  tasks,  over  and 
above  the  evaluation  of  the  material  submitted,  is  appropriate.  The  value  of  the  procurement,  the 
cost  of  the  determination,  the  staff  resources  available  to  perform  the  determination,  and  the 
development  risk  are  some  of  the  items  that  should  be  taken  into  account  in  determining  the 
appropriateness  of  a  determination  effort. _ 

►  The  statement  of  work,  including  software-related  tasks. 


Some  examples  of  software-related  tasks  include: 

engineering, 

evaluation, 

support, 

documentation,  and 

life  cycle  planning. _ 


►  The  contract  documentation  and  information  recording  requirements. 

Some  examples  of  contract  documentation  requirements  include: 

specifications; 

test  plans,  procedures,  reports; 
study  reports; 

configuration  management  plans,  procedures,  and  reports; 
administrative,  financial,  and  management  reports;  and 
project-specific  products  and  reports. _ 

►  The  contract  form  (e.g.,  completion  or  term),  contract  type  (e.g.,  fixed-price, 
cost-reimbursement),  incentives,  and  a  list  of  deliverable  supplies  and  services. 

►  Information  on  contract  acceptance  procedures,  specific  acceptance  criteria,  and 
payment. 

►  Additional  information  guiding  contractor  performance  during  the  contract,  including 
enabling  third-party  participation,  warranty  provisions,  and  required  data  rights. 
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Activity  2 


►  Guidance  on  how  the  offerors  are  to  respond,  how  the  responses  will  be  evaluated, 
and  any  additional  administrative  requirements  such  as  socioeconomic  program 
compliance. 

►  Documentation  requirements  for  the  offerors  to  submit  with  their  response. 


Some  examples  of  required  submissions  include: 

a  software  engineering  plan  describing  how  offerors  will  carry  out  the  software-related 
tasks  in  the  solicitation  package; 

a  risk  management  plan  describing  how  they  will  identify  and  manager  risks 
associated  with  the  software  related  risks  called  out  in  the  solicitation  package; 
identification  of  the  measurements  to  be  used  in  the  project  and  made  available  to 
the  project  office; 

a  statement  of  the  offeror’s  planned  use  of  NDI  and  COTS,  and  non-deliverable 
software,  including  any  limitation  on  data  rights; 

visibility  for  software  engineering  task  progress  and  costs  at  a  level  appropriate  for 
the  type  of  contract  and  commensurate  with  the  degree  of  risk  related  to  the 
software  acquisition;  and 

the  software-related  work  to  be  performed  by  subcontractors;  and 

providing  support  for  evaluation  and  acceptance. _ 


3.  The  participants,  responsibilities,  processes,  methodologies,  techniques,  and  schedules 
that  will  be  followed  in  the  conduct  of  the  solicitation. 

4.  The  proposal  evaluation  plans  typically  contain: 

►  A  description  of  the  proposal  evaluation  organization  structure,  including  the 
participants  and  their  responsibilities. 

►  Proposed  pre-evaluation  activities. 

►  A  summary  of  the  acquisition  strategy. 

►  A  statement  of  the  proposal  evaluation  factors  and  their  relative  importance. 

The  proposal  evaluation  factors  for  software  should  contain  factors  central  to  the  success  of  the 
software  item  or  service  being  acquired. _ 

►  A  description  of  the  proposal  evaluation  process,  methodology,  and  techniques  to  be 
used. 

Offerors  are  evaluated  based  on  their  past  performance,  including  domain  experience,  software 
development  process  maturity,  and  mature  software  products  in  the  relevant  domain. _ 

►  A  schedule  of  significant  proposal  evaluation  milestones. 

►  A  requirement  to  conduct  analyses  of  the  risks  associated  with  each  proposal. 

5.  A  process  for  managing  and  controlling  the  solicitation  documents. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

Solicitation  activities  are  conducted  in  a  manner  compliant  with  relevant 
laws,  policies,  and  guidance. 
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Solicitation 


Activity  3 


Activity  4 

Activity  5 
Activity  6 

Activity  7 
Activity  8 


The  software  and  evaluation  requirements  are  incorporated  into  the 
solicitation  package  and  resulting  contract. 

The  contract  provisions  typically  include: 

1.  Software  technical  and  non-technical  requirements  to  be  satisfied  by  the  contractor. 

2.  Requirements  for  the  contractor  to  document  a  plan  for  developing  the  software  products 
and  services. 

3.  Requirements  for  the  contractor  to  document  a  plan  for  evaluating  the  software  products 
and  services. 

4.  Measurements  that  provide  the  project  team  visibility  into  the  contractor  team’s 
development  and  evaluation  programs  and  results. 

5.  Mechanisms  and  deliverables  that  provide  the  project  team  sufficient  data  to  allow 
evaluation  and  analyses  of  acquired  software  products  and  services. 

6.  Requirements  for  the  contractor  to  establish  a  corrective  action  system  which  includes  a 
change  control  process  for  rework  and  reevaluation. 

7.  Requirements  to  ensure  the  contractor  team  supports  each  of  the  project’s  evaluation 
activities. 

Proposals  are  evaluated  in  accordance  with  documented  solicitation 
plans. 

Cost  and  schedule  estimates  for  the  software  products  and  services  being 
sought  are  prepared. 

Software  cost  and  schedule  estimates  are  independently  reviewed  for 
comprehensiveness  and  realism. 

In  this  instance,  “independently  reviewed”  means  a  review  by  an  individual(s)  other  than  the 
author(s)  of  the  cost  and  schedule  estimates. _ 


The  selection  official  uses  proposal  evaluation  results  to  support  his  or 
her  decision  to  select  an  offeror. 

The  project  team  takes  action  to  ensure  the  mutual  understanding  of 
software  requirements  and  plans  with  the  selected  offeror(s)  prior  to 
contract  signing. 
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Level  2:  The  Repeatable  Level 


Measurement  1 


Verification  1 


Verification  2 


Measurements  are  made  and  used  to  determine  the  status  of  the 
solicitation  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  solicitation  planning,  the 
statement  of  work,  contract  specifications,  evaluation  plans,  and 
cost  estimates;  and 

completion  of  milestones. _ 


Verifying  implementation 


Solicitation  activities  are  reviewed  by  the  acquisition  organization 
management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  the  solicitation  activities  at  an  appropriate 
level  of  abstraction.  The  reviews  verify  that  acquisition  organization  policy  is  being 
implemented.  The  time  between  reviews  should  satisfy  the  needs  of  the  organization 
and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception  reporting  are 
available. 


Solicitation  activities  are  reviewed  by  the  project  manager  or  designated 
selection  official  on  both  a  periodic  and  event-driven  basis. 
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Requirements  Development  and  Management 

a  key  process  area  for  Level  2:  Repeatable _ 


The  purpose  of  Requirements  Development  and  Management  is  to  establish  a  common  and 
unambiguous  definition  of  software-related  contractual  requirements  that  is  understood  by  the 
project  team,  end  user,  and  the  contractor  team.  Software-related  contractual  requirements 
consist  of  technical  requirements  (system  requirements  allocated  to  software)  and  non-technical 
requirements  (contractual  agreements,  conditions,  and  terms  affecting  the  software  portion  of  the 
acquisition).  This  key  process  area  is  divided  into  two  subprocesses;  development  of  software- 
related  contractual  requirements  and  the  management  of  these  requirements  for  the  duration  of 
the  acquisition. 

Software  requirements  development  involves  those  activities  in  which  system  level  requirements 
are  decomposed  and  allocated  to  software.  To  ensure  software  is  appropriately  addressed  during 
system  requirements  definition  and  solicitation  package  preparation,  the  project  team  participates 
with  the  overall  system  acquisition  team.  Reuse  of  existing  software  assets,  including 
architecture,  is  analyzed  for  use  in  satisfying  requirements.  Requirements  development  often 
involves  direct  participation  from  the  end  user  to  ensure  that  system-level  requirements  are  well 
understood. 

Software  requirements  management  involves  establishing  and  maintaining  agreement  among  the 
project  team,  including  the  end  user,  and  contractor  team  with  respect  to  the  software-related 
contractual  requirements.  It  involves  baselining  the  software  requirements  and  controlling  all 
subsequent  requirements  changes.  This  key  process  area  and  the  contract  address  both  technical 
and  non-technical  software  requirements. 

Requirements  development  and  management  begins  with  the  translation  of  operational  or  end 
user  requirements  into  solicitation  documentation  (e.g.,  specifications)  and  ends  with  the  transfer 
of  responsibility  for  the  support  of  the  software  products. 

Software-related  contractual  requirements  define  the  scope  of  the  software  effort.  Software- 
related  contractual  requirements  are  incorporated  into  software  project  plans,  activities,  and 
products  in  an  orderly  manner.  Requirements  management  ensures  that  software  requirements 
are  unambiguous,  traceable,  verifiable,  documented,  and  controlled. 
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Goals 


Goal  1  Software-related  contractual  requirements  are  developed,  managed,  and 

maintained. 

Goal  2  The  end  user  and  other  affected  groups  have  input  to  the  software-related 

contractual  requirements  over  the  life  of  the  acquisition. 

Goal  3  Software-related  contractual  requirements  are  traceable  and  verifiable. 

Goal  4  The  software-related  contractual  requirements  baseline  is  established 

prior  to  release  of  the  solicitation  package. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  establishing  and 
managing  the  software-related  contractual  requirements. 

1 .  This  policy  typically  specifies  that: 

►  Software-related  contractual  requirements  are  documented. 

►  Software-related  contractual  requirements  are  reviewed  by: 

*  Project  management. 

*  Other  affected  groups. 

Some  examples  of  affected  groups  include: 
end  user, 

project  system  engineering, 
project  evaluation, 
project  quality  assurance, 
software  support  organization,  and 
project  configuration  and  data  management. 

►  Changes  to  the  software-related  contractual  requirements  are  reflected  in  software 
acquisition  plans,  work  products,  services,  and  activities. 

►  A  change  control  mechanism  exists  to  manage  and  control  changes  to  the  software- 
related  contractual  requirements. 


“Managed  and  controlled”  implies  that  the  software  requirements  are  baselined,  the  version  of 
the  software  requirements  at  a  given  time  (past  or  present)  is  known  (i.e.,  version  control),  and 
the  changes  are  incorporated  in  a  controlled  manner  (i.e„  change  control). _ 


2.  Software  requirements  include: 
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Commitment  2 

Ability  1 
AbUity  2 


Ability  3 


►  Non-technical  requirements  (e.g.,  the  contractual  agreements,  conditions,  and  terms) 
that  affect  and  determine  the  activities  of  the  software  acquisition  project. 


Some  examples  of  contractual  agreements,  conditions,  and  terms  include: 

products  to  be  delivered, 
data  rights  for  delivered  COTS/NDI, 
intellectual  property  rights, 
delivery  dates,  and 
milestones  with  exit  criteria. 


►  Technical  requirements  for  the  software. 

Some  examples  of  technical  requirements  include: 

functional  requirements, 
performance  requirements, 
security  requirements, 
quality  requirements, 
design  constraints, 
architectural  constraints, 
reuse  requirements, 
supportability  requirements, 
external  interface  requirements,  and 
standards.  _ 


Responsibility  for  requirements  development  and  management  is 
designated. 

Ability  to  perform 


A  group  that  is  responsible  for  performing  requirements  development 
and  management  activities  exists. 

Adequate  resources  are  provided  for  requirements  development  and 
management  activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 


|  Tools  to  support  the  activities  for  managing  software-related  contractual  requirements  may  include: 

spreadsheet  programs, 
configuration  management  tools, 
traceability  tools, 
lexical  analysis  tools, 
specification  modeling  tools, 
evaluation  management  tools,  and 

prototyping  tools. _ 


Individuals  performing  requirements  development  and  management 
activities  have  experience  or  receive  training. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition 
management  role  on  at  least  one  project  and  having  experience  in  the  domain  of  the 
application  being  acquired. _ 
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Activity  1 


Some  examples  of  training  include: 

the  methods,  standards,  and  procedures  used  by  the 
project; 

the  application  domain;  and 
architectures. 


Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  requirements  development  and  management  plans. 

The  plans  typically  cover: 

1.  The  objectives  of  the  project  team’s  requirements  development  and  management 
activities. 

2.  The  activities  to  be  performed,  including  requirements  definition. 

3.  Identification  of  the  groups,  and  intergroup  coordination,  associated  with  requirements 
development  and  management  activities. 

Some  examples  of  groups  include: 

potential  bidders, 
project  system  engineering, 
project  cost  analysis, 

project  configuration  and  data  management, 

project  evaluation, 

product-line  management, 

project  quality  assurance,  and 

end  user.  _  _ 


4.  Procedures  for  requirements  development,  including  planning,  elicitation,  analysis,  and 
verification. 

5.  Procedures  for  requirements  management,  including  baseline  establishment,  change 
control,  and  status  reporting. 

6.  Procedures  to  define  attributes  that  describe  a  “satisfactory”  requirement. 


Some  examples  of  criteria  for  satisfactory  requirements  are: 

correctness, 

completeness, 

consistency, 

clarity, 

non-ambiguity, 
verifiability, 
traceability,  and 

feasibility. _ 
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Activity  2 


Activity  3 

Activity  4 


7.  Procedures  for  impact  analysis  of  changes  to  requirements  or  introduction  of  new 
requirements,  including  performance,  cost,  and  schedule. 

8.  Resource  requirements  and  schedules  to  perform  requirements  development  and 
management  activities. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

The  project  team  develops,  baselines,  and  maintains  software-related 
contractual  requirements  and  places  them  under  change  control  early  in 
the  project,  but  not  later  than  release  of  the  solicitation  package. 

1.  Baselined  software-related  contractual  requirements  are  documented. 

2.  Software-related  contractual  requirements  are  reviewed  for  completeness, 
understandability,  verifiability,  and  priority. 

3.  Acceptance  criteria  for  software-related  contractual  requirements  are  established  and 
controlled. 

4.  Changes  to  the  baseline  are  managed  and  controlled. 

The  project  team  appraises  system  requirements  change  requests  for 
their  impact  on  the  software  being  acquired. 

The  project  team  appraises  all  changes  to  the  software-related 
contractual  requirements  for  their  impact  on  performance,  architecture, 
supportability,  system  resource  utilization,  and  contract  schedule  and 
cost. 

1.  The  impact  on  existing  commitments  is  determined  and  changes  in  commitments  are 
negotiated  as  appropriate. 

Some  examples  of  changes  include: 

Changes  to  commitments  made  to  individuals  and  groups  external  to  the  acquisition  organization 
and 

changes  to  commitments  within  the  acquisition  organization. _ 

2.  Changes  to  software  acquisition  plans,  work  products,  services,  or  activities  resulting 
from  changes  in  software-related  contractual  requirements  are: 

►  Identified. 

►  Appraised  for  potential  impact. 

►  Analyzed  for  risk. 

►  Documented. 
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Activity  5 


Activity  6 


Measurement  1 


Verification  1 


►  Communicated  to  the  affected  groups  and  individuals. 

►  Tracked  to  completion. 

Bi-directional  traceability  between  the  contractual  requirements  and  the 
contractor  team’s  software  work  products  and  services  is  maintained 
throughout  the  effort. 


Some  examples  of  mechanisms  providing  this  traceability  include: 

the  project  team  itself  performs  and  maintains  this  traceability  and 

the  project  team  tasks  the  contractor  team  (or  other)  to  perform  and  maintain  the 

traceability. _ 


The  end  user  and  other  affected  groups  are  involved  in  the  development 
of  all  software-related  contractual  requirements  and  any  subsequent 
change  activity. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
requirements  development  and  management  activities  and  resultant 
products. 


Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  requirements  development  and  management 
planning,  the  initial  software  requirements,  and  baselining  the  software 
requirements; 

number  of  change  requests  appraised;  and 

completion  of  milestones. _ 


Verifying  implementation 


Requirements  development  and  management  activities  are  reviewed  by 
acquisition  organization  management  (and  the  contractor)  on  a  periodic 
basis. 
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Verification  2 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  requirements  development  and  management 
activities  at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 


Requirements  development  and  management  activities  are  reviewed  by 
the  project  manager  on  both  a  periodic  and  event-driven  basis. 
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Project  Management _ 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Project  Management  is  to  manage  the  activities  of  the  project  office  and 
supporting  organizations  to  ensure  a  timely,  efficient,  and  effective  software  acquisition. 

Project  Management  involves  planning,  organizing,  staffing,  directing,  and  controlling  project 
activities,  such  as  determining  project  tasks,  estimating  software  effort  and  cost,  scheduling 
activities  and  tasks,  training,  leading  the  assigned  personnel,  and  accepting  software  products  and 
services. 

Project  management  begins  when  the  project  office  is  officially  chartered  and  terminates  when 
the  acquisition  is  completed. 

I 

Goals 


Goal  1  Project  management  activities  are  planned,  organized,  controlled,  and 

communicated. 

Goal  2  The  performance,  cost,  and  schedule  objectives  of  the  software 

acquisition  project  are  measured  and  controlled  throughout  the  software 
acquisition. 

Goal  3  Problems  discovered  during  the  software  acquisition  are  managed  and 

controlled. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  execution  of  the 
software  project. 

This  policy  typically  specifies  that: 

1.  The  software-related  requirements  are  used  as  the  basis  for  planning  the  software 
acquisition  project. 

Refer  to  the  Requirements  Development  and  Management  key  process  area. 
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Commitment  2 

Ability  1 

Ability  2 


Ability  3 


2.  The  software  acquisition  project’s  commitments  are  coordinated  among  the  affected 
managers. 

3.  Involvement  of  other  affected  groups  in  the  software  acquisition  activities  is  negotiated 
and  documented. 


Some  examples  of  affected  groups  include: 

operational  test  group, 

system  engineering  group, 

software  engineering  group,  and 

end  user  representatives. _ 

4.  Acquisition  organization  management  reviews  all  software-related  project  commitments 
made  to  individuals  and  groups  external  to  the  organization. 

5.  The  project’s  software  acquisition  plans  are  managed  and  controlled. 

6.  A  corrective  action  system  is  to  be  established  by  the  project  team  to  record  problems  and 
issues  discovered. 

Responsibility  for  project  management  is  designated. 

Ability  to  perform 


A  team  that  is  responsible  for  performing  the  project’s  software 
acquisition  management  activities  exists. 

Adequate  resources  for  the  project  team  are  provided  for  the  duration  of 
the  software  acquisition  project. 

1.  The  project  office  allocates  sufficient  funds  for  internal  operations,  matrix  support, 
contractual  efforts,  and  specific  mission  areas  of  responsibility. 

2.  The  project  office  is  staffed  with  the  proper  number  and  kinds  of  people  to  address 
internal  responsibilities  and  matrix  support  needed  to  accomplish  the  project’s  activities. 

3.  The  project  office  plans  for  and  provides  the  equipment  needed  to  accomplish  the 
project’s  activities. 

4.  The  project  office  plans  for  and  provides  the  tools  needed  to  accomplish  the  project’s 
activities. 

When  project  trade-offs  are  necessary,  the  project  manager  is  permitted 
to  alter  the  performance,  cost,  or  schedule  software  acquisition  baseline. 
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Ability  4  The  project  team  has  experience  or  receives  training  in  project  software 

acquisition  management  activities. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition 
management  role  on  at  least  one  project  and  having  experience  in  the  domain  of  the 
application  being  acquired.  Additionally,  some  individuals  should  have  general 
management  skills  as  well  as  budgeting  and  scheduling  experience. _ 


Activities  performed 


Activity  1  The  project  team  performs  its  activities  in  accordance  with  its 

documented  software  acquisition  management  plans. 

Project  software  acquisition  management  plans  typically  contain  or  reference  documents  that 
contain: 

1.  Project  objectives,  purpose,  scope,  and  duration. 

2.  Project  summary  and  authorization. 

3.  Project  team  structure,  roles,  and  responsibilities. 

4.  Resource  requirements. 

5.  Acquisition  strategy. 

6.  Project  performance,  cost,  and  schedule  baselines. 

7.  Coordination  and  communication. 

8.  Risk  identification  and  tracking. 

9.  Relationship  to  systems  engineering. 

10.  Software  engineering  approach. 

1 1 .  Installation  of  the  Software  Engineering  Environment  and  other  products  of  the 
contract. 

12.  Integrated  logistics  support  requirements. 

13.  Software  support  requirements. 

14.  Security  policy  and  requirements. 

15.  Corrective  action  reporting  procedures. 

16.  The  extent  of  end  user  involvement  in  the  acquisition. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 
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Activity  2  The  roles,  responsibilities,  and  authority  for  the  project  functions  are 

documented,  maintained,  and  communicated  to  affected  groups. 

Activity  3  The  project  team’s  commitments,  and  changes  to  commitments,  are 

communicated  to  affected  groups. 

Activity  4  The  project  team  tracks  the  risks  associated  with  cost,  schedule, 

resources,  and  the  technical  aspects  of  the  project 

1.  The  priorities  of  the  risks  and  the  contingencies  for  the  risks  are  adjusted  as  additional 
information  becomes  available. 

2.  High  risk  areas  are  reviewed  with  acquisition  organization  management  on  a  regular 
basis. 

Activity  5  The  project  team  tracks  project  issues,  status,  execution,  funding,  and 

expenditures  against  project  plans  and  takes  action. 

Activity  6  The  project  team  implements  a  corrective  action  system  for  the 

identification,  recording,  tracking,  and  correction  of  problems  discovered 
during  the  software  acquisition. 

Activity  7  The  project  team  keeps  its  plans  current  during  the  life  of  the  project  as 

replanning  occurs,  issues  are  resolved,  requirements  are  changed,  and 
new  risks  are  discovered. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  project 
management  activities  and  resultant  products. 
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Project  Management 


Level  2:  The  Repeatable  Level 


Verification  1 


Verification  2 


Verifying  implementation 


Project  management  activities  are  reviewed  by  acquisition  organization 
management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  project  management  activities  at  an 
appropriate  level  of  abstraction.  The  reviews  verily  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Project  management  activities  are  reviewed  by  the  project  manager  on 
both  a  periodic  and  event-driven  basis. 
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Contract  Tracking  and  Oversight 


Contract  Tracking  and  Oversight 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Contract  Tracking  and  Oversight  is  to  ensure  that  the  software  activities  under 
contract  are  being  performed  in  accordance  with  contractual  requirements. 

Contract  Tracking  and  Oversight  involves  providing  ongoing  inputs  and  guidance  to  the 
contractor’s  effort  and  identifying  risks  and  problems  in  the  effort. 

Contract  tracking  and  oversight  begins  with  the  award  of  the  contract  and  ends  at  the  conclusion 
of  the  contract’s  period  of  performance. 

The  contract  provides  the  binding  agreement  for  establishing  the  requirements  for  the  software 
products  and  services  to  be  acquired.  It  establishes  the  mechanism  to  allow  the  project  team  to 
oversee  the  contractor  team’s  software  activities  and  evolving  products  and  to  evaluate  any 
software  products  and  services  being  acquired.  It  also  provides  the  vehicle  for  mutual 
understanding  between  the  project  team  and  the  contractor  of  the  software  requirements  of  the 
contract. 


Goals 


Goal  1  The  project  team  has  sufficient  insight  into  the  contractor’s  software 

engineering  effort  to  ensure  the  effort  is  managed  and  controlled  and 
complies  with  contract  requirements. 

Goal  2  The  project  team  and  contractor  team  maintain  ongoing  communication 

and  commitments  are  agreed  to  by  both  parties. 

Goal  3  The  contract,  and  any  changes,  adhere  to  relevant  laws,  policies, 

regulations,  and  other  planned  guidance  and  implements  project  software 
acquisition  requirements. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  contract 
tracking  and  oversight  of  the  contracted  software  effort. 

This  policy  typically  specifies  that: 
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Contract  Tracking  and  Oversight 


Level  2:  The  Repeatable  Level 


Commitment  2 
Commitment  3 

Ability  1 

Ability  2 

Ability  3 


Activity  1 


1 .  Planning  for  contract  tracking  and  oversight  is  documented. 

2.  Contract  tracking  and  oversight  plans  are  managed  and  controlled. 

3.  Applicable  tools  and  methodologies  are  to  be  used  to  track  the  contracted  effort. 

4.  The  integrity  of  the  contract  is  to  be  maintained  throughout  the  contract  performance 
period. 

5.  Software  efforts  are  to  be  addressed  at  reviews  of  contractor  team  performance. 

Responsibility  for  contract  tracking  and  oversight  activities  is  designated. 

The  project  team  includes  contracting  specialists  in  the  execution  of  the 
contract. 

Ability  to  perform 


A  group  that  is  responsible  for  managing  contract  tracking  and  oversight 
activities  exists. 

Adequate  resources  are  provided  for  contract  tracking  and  oversight 
activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Individuals  performing  contract  tracking  and  oversight  activities  have 
experience  or  receive  training. 


Experience  means,  for  example,  having  participated  on  at  least  one  software  project 
in  areas  of  tracking  software  development  under  contract,  providing  technical 
guidance  to  contractors,  and  correctly  applying  contractual  and  legal  policies  and 
regulations  for  that  effort. _ 


Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  contract  tracking  and  oversight  plans. 

The  plans  typically  cover: 

1.  Guidelines  and  criteria  used  in  defining  the  project  team’s  contract  tracking  and  oversight 
activities. 
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Level  2:  The  Repeatable  Level 


Contract  Tracking  and  Oversight 


Activity  2 


Activity  3 


2.  Activities  to  be  performed  and  the  schedule  to  perform  these  activities. 

3.  Identification  of  groups,  assigned  responsibilities,  and  intergroup  coordination. 

4.  End  user  involvement. 

5.  Techniques,  tools,  and  methodologies  to  be  employed  for  review  and  tracking  of 
contractor  team  performance  and  compliance  of  the  evolving  software  products  and 
services. 

6.  Resources  required  to  accomplish  contract  tracking  and  oversight  activities. 

7.  Procedures  to  be  followed  to  track  and  identify  issues  to  closure. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 


The  project  team  reviews  required  contractor  software  planning 
documents  which,  when  satisfactory,  are  used  to  oversee  the  contractor 
team’s  software  engineering  effort. 


Changes  to  these  plans  are  to  be  coordinated  with  the  project  team  before  being 
implemented  by  the  contractor  team. _ 


Some  examples  of  contractor  planning  documents  that  may  be 
required  include: 
project  management, 
software  risk  management, 
software  engineering, 
reuse, 

configuration  management,  and 

subcontractor  management. _ 


The  project  team  conducts  periodic  reviews  and  interchanges  with  the 
contractor  team. 


These  reviews  may  include  end  user  and  other 
affected  groups  input  as  needed. _ 

These  reviews  typically  attempt  to  ensure: 

1.  Continuing  communications  and  mutual  understanding  of  the  contractual  software 
requirements. 

2.  The  contractor  team  is  implementing  activities  according  to  approved  plans. 

3.  Open  issues  with  the  contractor  are  resolved. 

4.  The  contractor’s  activities  and  results  are  addressed. 

5.  The  contractor  team’s  evaluations  of  the  software  products  and  services  comply  with 
approved  evaluation  plans  and  procedures. 
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Contract  Tracking  and  Oversight 


Level  2:  The  Repeatable  Level 


Activity  4 


Activity  5 


Activity  6 


Activity  7 


Activity  8 


6.  The  contractor’s  corrective  action  system,  including  deficiency  reporting,  deficiency 
correction,  re-testing,  and  rework,  is  being  implemented  according  to  approved  plans  and 
procedures. 

7.  The  software  requirements  being  analyzed  and  documented  by  the  contractor  team  are 
unambiguous,  traceable,  testable,  documented,  and  controlled. 

8.  Evolving  software  products  and  services  will  satisfy  software-related  contractual  non¬ 
technical  and  technical  requirements,  including  functional,  performance,  operational, 
supportability,  and  other  quality  requirements. 

Refer  to  the  Evaluation  key  process  area  for  evaluation  of  evolving  products  and 
services. 

9.  Issues  are  identified  and  plans  developed  for  their  resolution. 

The  actual  cost  and  schedule  of  the  contractor’s  software  engineering 
effort  are  compared  to  planned  schedules  and  budgets  and  issues  are 
identified. 


Some  examples  of  contractor  team  progress 
tracking  include: 

contract  work  packages, 
periodic  progress  measurements, 
earned  value  practices,  and 
performance  evaluations. _ 


The  size,  critical  computer  resources,  and  technical  activities  associated 
with  the  contractor  team’s  work  products  are  tracked  and  issues 
identified. 

The  project  team  reviews  and  tracks  the  development  of  the  software 
engineering  environment  required  to  provide  life  cycle  support  for  the 
acquired  software  and  issues  are  identified. 

Any  issues  found  by  the  project  team  during  contract  tracking  and 
oversight  are  recorded  in  the  appropriate  corrective  action  system,  action 
taken,  and  tracked  to  closure. 


The  appropriate  corrective  action  system  can  be  either  the  project  team’s  or  the 
contractor’s. 


The  project  team  ensures  that  changes  to  the  software-related  contractual 
requirements  are  coordinated  with  all  affected  groups  and  individuals, 
such  as  the  contracting  official,  contractor,  and  end  user. 
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Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the  contract 
tracking  and  oversight  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  contract  tracking  and  oversight  planning  and 
baselining  contractor  planning  documents, 

number  of  items  closed  in  the  corrective  action  system  used  by  the  project  team, 
and 

completion  of  milestones. _ 


Verifying  implementation 


Verification  1  Contract  tracking  and  oversight  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  contract  tracking  and  oversight  activities  at  an 
appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Verification  2 


Contract  tracking  and  oversight  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 


CMU/SEI-99-TR-002 


L2-29 


Evaluation 


Level  2:  The  Repeatable  Level 


Evaluation _ 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Evaluation  is  to  provide  objective  evidence  that  the  evolving  software  products 
and  services  satisfy  contract  requirements  prior  to  acceptance  and  transition  to  support. 

Evaluation  involves  the  development  of  requirements  for  the  evaluation  approach,  including 
acceptance  criteria,  which  are  incorporated  into  both  the  solicitation  package  and  the  contract. 
Evaluations  are  conducted  throughout  the  contract  performance  period  and  results  are  analyzed  to 
determine  acceptability  of  the  software  products  and  services.  Evaluation  activities  are  designed 
to  reduce  interference  with  contractor-performed  evaluations  and  to  reduce  duplication  of 
evaluation  efforts.  Evaluation  supports  the  activities  that  establish  and  verify  the  contractual 
requirements.  Evaluation  interacts  with  the  Solicitation,  Requirements  Development,  and 
Contract  Tracking  and  Oversight  key  process  areas. 

Evaluation  begins  with  development  of  the  system  requirements  and  ends  when  the  software 
acquisition  is  completed. 

Goals 


Goal  1  Evaluation  requirements  are  developed  in  conjunction  with  the  technical 

requirements  and  are  maintained  over  the  life  of  the  acquisition. 

Goal  2  Evaluations  are  planned  and  conducted  throughout  the  total  period  of  the 

acquisition  to  provide  an  integrated  approach  that  satisfies  evaluation 
requirements  and  takes  advantage  of  all  evaluation  results. 

Goal  3  Evaluations  provide  an  objective  basis  to  support  the  decision  for 

acceptance  of  the  software  products  and  services. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  managing  the 
evaluation  of  the  acquired  software  products  and  services. 

This  policy  typically  specifies  that: 
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Evaluation 


Commitment  2 


Ability  1 


1.  Evaluations  are  intended  to  reduce  acquisition  risk  and  to  estimate  effectiveness  and 
suitability  of  the  software  products  and  services  to  support  the  satisfaction  of  end  user 
needs. 

2.  The  project  includes  plans  for  the  evaluation  of  the  acquired  software  products  and 
services  which  specify  evaluation  objectives  and  evaluation  criteria. 

3.  The  project’s  evaluation  activities  begin  with  the  development  of  the  software-related 
contractual  requirements. 


Refer  to  the  Requirements  Development  and  Management  key  process  area. 

4.  The  project  defines  the  evaluation  requirements  for  the  acquisition. 

Some  examples  of  evaluation  requirements  include: 

documented  evaluation  approach  involving  the  project  team,  contractor  team,  and  other  affected 
groups; 

contractor  evaluation  activities,  or  tasks  required; 
contractor  deliverables  such  as  test  plans  and  reports;  and 

integration  evaluation  schedule. _ 

5.  Results  of  the  evaluations  are  used  as  a  basis  for  acceptance  of  the  software  products  and 
services. 

6.  The  project’s  software  evaluation  planning  is  updated  to  reflect  changes  to  the  software 
requirements. 

Responsibility  for  evaluation  activities  is  designated. 

Ability  to  perform 


A  group  that  is  responsible  for  planning,  managing,  and  performing 
evaluation  activities  for  the  project  exists. 

The  evaluation  group  may  include: 

1.  Independent  evaluators. 

2.  End  users. 

3.  Software  support  organization. 

4.  System  and  software  engineers. 

5.  Members  of  the  software  requirements  development  and  management  group. 

Refer  to  the  Requirements  Development  and  Management  key  process  area. 
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Level  2:  The  Repeatable  Level 


Ability  2 


Ability  3 


Ability  4 


Activity  1 


Adequate  resources  are  provided  for  evaluation  activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 


Some  examples  of  tools  to  support  software  evaluation  activities  include: 

data  collection  tools, 

test  environments, 

static  code  analyzers, 

problem  tracking  software  packages, 

configuration  management  tools,  and 

traceability  tools. _ 


Individuals  performing  evaluation  activities  have  experience  or  receive 
training. 


Experience  means,  for  example,  having  developed  methods  for  the  evaluation  of 
software  products  and  services,  having  applied  basic  analysis  techniques,  and  having 
evaluated  product  quality  data  on  at  least  one  project. _ 


Members  of  the  project  team  and  groups  supporting  the  software 
acquisition  receive  orientation  on  the  objectives  of  the  evaluation 
approach. 

Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  evaluation  plans. 

The  plans  typically  cover: 

1.  A  summary  of  the  operational  need  and  key  operational  effectiveness  or  suitability  issues 
that  must  be  addressed  by  evaluation. 

2.  A  brief  description  of  the  system  and  key  areas  of  technical  or  engineering  risk  that  must 
be  addressed  by  evaluation. 

3.  A  brief  description  of  the  integrated  evaluation  approach,  including  evaluation  objectives, 
the  evaluation  activities  to  be  performed,  and  the  integrated  schedule  for  these  activities. 

4.  The  groups  responsible  for  conducting  evaluation  activities. 

5.  A  summary  of  the  resources  required  to  perform  the  evaluations. 

6.  The  actions  to  be  taken  when  software  product  or  service  quality  is  determined  or 
projected  to  fall  short  of  established  requirements. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 
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Evaluation 


Activity  2 


Activity  3 

Activity  4 


Activity  5 


Activity  6 


The  project’s  evaluation  requirements  are  developed  in  conjunction  with 
the  development  of  the  system  or  software  technical  requirements. 

1.  Development  of  evaluation  requirements  involves  groups  participating  in  evaluation 
activities,  including  the  end  users. 

2.  Development  of  evaluation  requirements  may  involve: 

►  Identifying  the  system  or  software  requirements  to  be  evaluated. 

►  Identifying  architectural  compliance  issues  to  be  evaluated. 

►  Establishing  objective  evaluation  and  acceptance  criteria. 

►  Designing  detailed  activities  to  perform  the  evaluations. 

►  Identifying  how  to  evaluate  the  quality  of  the  acquired  software  products  and 
services. 

►  Identifying  requisite  resources  and  ensuring  that  these  resources  will  be  in  place. 

►  Developing  a  detailed  schedule  of  activities. 

►  Ensuring  traceability  of  evaluation  requirements  to  system  requirements. 

The  project’s  evaluation  activities  are  planned  to  minimize  duplication 
and  take  advantage  of  all  evaluation  results,  where  appropriate. 

The  project  team  appraises  the  contractor  team’s  performance  over  the 
total  period  of  the  contract  for  compliance  with  requirements. 


Any  problems  or  issues  such  as  areas  of  non-compliance  found  by  evaluation  activities 
are  recorded  in  the  appropriate  corrective  action  system. _ 


Refer  to  Activity  3  of  the  Contract  Tracking  and  Oversight  key  process  area. 


Planned  evaluations  are  performed  on  the  evolving  software  products 
and  services  prior  to  acceptance  for  operational  use. 


As  part  of  the  planned  integrated  approach,  complementary  evaluations  may  be 
performed  independently  by  the  project  team  (with  support  of  the  contractor  team)  to 
further  reduce  the  risk  that  the  acquired  software  products  and  services  will  fail  to 
satisfy  contractual  requirements. _ 


Results  of  the  evaluations  are  analyzed  and  compared  to  the  contract’s 
requirements  to  establish  an  objective  basis  to  support  the  decision  to 
accept  the  products  and  services  or  to  take  further  action. 
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Level  2:  The  Repeatable  Level 


Measurement  1 


Verification  1 


Verification  2 


Measurements  are  made  and  used  to  determine  the  status  of  the 
evaluation  activities  and  resultant  products. 


Some  examples  of  measurements  include: 
effort  expended, 
funds  expended, 

progress  towards  completion  of  evaluation 
planning  and  of  evaluation  requirements,  and 
completion  of  milestones. _ 


Verifying  implementation 


Evaluation  activities  are  reviewed  by  acquisition  organization 
management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  evaluation  activities  at  an  appropriate  level  of 
abstraction.  The  reviews  verify  that  acquisition  organization  policy  is  being 
implemented.  The  time  between  reviews  should  satisfy  the  needs  of  the  organization 
and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception  reporting  are 
available. 


Evaluation  activities  are  reviewed  by  the  project  manager  on  both  a 
periodic  and  event-driven  basis. 
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Transition  to  Support 


Transition  to  Support _ 

a  key  process  area  for  Level  2:  Repeatable 


The  purpose  of  Transition  to  Support  is  to  provide  for  the  transition  of  the  software  products 
being  acquired  to  the  eventual  software  support  organization.  The  necessary  resources  are 
identified,  budgeted  for,  and  are  available  when  needed.  The  designated  software  support 
organization  is  fully  prepared  to  accept  responsibility  for  the  software  products  in  time  to  ensure 
uninterrupted  support. 

Transition  to  Support  involves  developing  and  implementing  the  plans  for  transitioning  the 
acquired  software  products.  It  also  involves  ensuring  that  the  contractor  team  and  the  software 
support  organization  are  informed  on  the  contents  of  the  software  engineering  and  support 
environments.  The  project  team  provides  for  an  Orderly,  smooth  transition  of  the  software 
products  from  the  contractor  team  to  the  software  support  organization. 

Transition  to  support  begins  with  the  earliest  definition  of  software  requirements  and  ends  when 
the  responsibility  for  the  software  products  is  turned  over  to  the  software  support  organization. 

Goals 


Goal  1  The  project  team  ensures  the  software  support  organization  has  the 

capacity  and  capability  to  provide  the  required  support  upon  assumption 
of  responsibility  for  the  support  of  the  software  products. 

Goal  2  There  is  no  loss  in  continuity  of  support  to  the  software  products  during 

transition  from  the  contractor  to  the  software  support  organization. 

Goal  3  Configuration  management  of  the  software  products  is  maintained 

throughout  the  transition. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  transitioning  of 
software  products  to  the  software  support  organization. 

This  policy  typically  specifies  that: 

1 .  The  software  support  organization  is  identified  prior  to  developing  the  solicitation 
package. 
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Transition  to  Support 


Level  2:  The  Repeatable  Level 


Commitment  2 

Commitment  3 

Ability  1 

Ability  2 

Ability  3 

Ability  4 


Ability  5 


2.  Resources  for  software  support  are  included  in  the  appropriate  budget(s). 

3.  The  designated  software  support  organization  is  involved,  as  appropriate,  throughout  the 
acquisition. 

The  acquisition  organization  ensures  that  the  software  support 
organization  is  involved  in  planning  for  transition  to  support. 

Responsibility  for  transition  to  support  activities  is  designated. 

Ability  to  perform 


A  group  that  is  responsible  for  coordinating  transition  to  support 
activities  exists. 

Adequate  resources  are  provided  for  transition  to  support  activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

The  organization  responsible  for  providing  support  of  the  software 
products  is  identified  no  later  than  initiation  of  the  solicitation  package’s 
development. 

The  software  support  organization,  prior  to  transition,  has  a  complete 
inventory  of  all  software  and  related  items  that  are  to  be  transitioned. 


Some  examples  of  related  items  include: 

software  descriptive  documentation, 
necessary  support  software, 
reusable  software  assets, 
pertinent  data  from  the  corrective  action 
and  configuration  management  systems, 
and 

maintenance  documentation. 


Individuals  performing  transition  to  support  activities  have  experience  or 
receive  training. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition 
management  role  on  at  least  one  project  and  having  participated  in  supporting 
software  for  at  least  two  years. _ 
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Transition  to  Support 


Ability  6 


Activity  1 


Activity  2 


The  members  of  organizations  interfacing  with  the  transition  to  support 
activities  receive  orientation  on  the  salient  aspects  of  transition  to  support 
activities. 

Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  transition  to  support  plans. 

The  plans  typically  cover: 

1.  The  objectives  and  scope  of  the  transition  to  support  activities. 

2.  Identification  and  involvement  of  the  software  support  organization. 

3.  Support  resource  requirements. 

4.  A  definition  of  transition  activities. 

5.  A  schedule  of  transition  activities. 

6.  Allocation  of  transition  responsibilities. 

7.  Installation  of  products  that  are  to  be  delivered. 

8.  Warranty  and  data  rights  provisions. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

Responsibility  for  the  software  products  is  transferred  only  after  the 
software  support  organization  demonstrates  its  capability  and  capacity  to 
modify  and  support  the  software  products. 

This  capability  typically  includes  the  availability  of: 

1.  Hardware,  software,  physical,  fiscal,  and  personnel  resources. 

2.  Plans,  processes,  procedures,  and  documentation. 

3.  An  established  configuration  management  system  capable  of  supporting  the  software. 

4.  Appropriate  training  of  all  personnel  involved. 

5.  Software  replication,  test,  and  distribution  capabilities. 
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Activity  3 


Activity  4 


Measurement  1 


Verification  1 


Verification  2 


The  project  team  conducts  activities  to  ensure  that  support  of  the 
software  products  is  maintained  and  is  effective  during  the  transition 
from  the  contractor  to  the  software  support  organization. 

The  project  team  oversees  the  configuration  control  of  the  software 
products  throughout  the  transition. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
transition  to  support  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  transition 

to  support  planning,  and 

completion  of  milestones. _ 


Verifying  implementation 


Transition  to  support  activities  are  reviewed  by  acquisition  and  software 
support  organizations’  managements  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  and  software  support 
organizations’  management  is  to  provide  awareness  of,  and  insight  into,  transition  to 
support  activities  at  an  appropriate  level  of  abstraction.  The  reviews  verify  that 
acquisition  organization  policy  is  being  implemented.  The  time  between  reviews 
should  satisfy  the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate 
mechanisms  for  exception  reporting  are  available. _ 


Transition  to  support  activities  are  reviewed  by  the  project  manager  on 
both  a  periodic  and  event-driven  basis. 
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At  the  Defined  Level,  the  acquisition  organization’s  standard  software  acquisition  process  is 
established,  including  the  processes  for  both  software  contract  management  and  project 
management,  and  its  use  is  integrated  into  each  project.  The  acquisition  organization  exploits 
effective  software  acquisition  techniques  when  standardizing  software  acquisition  processes. 
There  is  a  permanent  focus  on  the  process;  the  acquisition  organization’s  software  acquisition 
process  group  facilitates  process  definition  and  maintenance  efforts.  Processes  established  at  the 
Defined  Level  are  tailored  as  appropriate  to  perform  more  effectively  within  the  project.  An 
organization-wide  training  program  is  implemented  to  ensure  that  all  practitioners  and  managers 
have  the  knowledge  and  skills  required  to  carry  out  their  tasks. 

Projects  use  the  acquisition  organization’s  standard  software  acquisition  process  as  a  basis  for 
creating  their  own  defined  software  acquisition  process  that  encompasses  the  unique 
characteristics  of  the  project.  Because  the  acquisition  organization’s  standard  software 
acquisition  process  is  well  defined  and  understood,  management  has  good  visibility  into  technical 
progress  of  the  project.  Management  and  engineering  activities  are  coherently  integrated  on  each 
project.  When  attempting  to  comply  with  required  policy,  the  project  team  is  capable  of 
balancing  the  intent  of  the  policy  with  a  conflicting  project  need.  The  project  team  ensures 
compliance  with  plans  and  contract  requirements  and  works  with  the  contractor  to  resolve 
compliance  difficulties  when  they  arise.  Risks  are  identified  and  managed  throughout  the 
acquisition. 

The  process  capability  of  Level  3  acquisition  organizations  can  be  summarized  as  being 
controlled,  since  performance,  cost,  schedule,  and  requirements  are  under  control  and  software 
quality  is  tracked.  This  capability  is  based  on  a  common  understanding  of  processes,  roles,  and 
responsibilities  in  a  defined  acquisition  process. 

Level  3  key  process  areas  are: 

Process  Definition  and  Maintenance 
Project  Performance  Management 
Contract  Performance  Management 
Acquisition  Risk  Management 
Training  Program 


CMU/SEI-99-TR-002 


L3-1 


Process  Definition  and  Maintenance 


Level  3:  The  Defined  Level 


Process  Definition  and  Maintenance 

a  key  process  area  for  Level  3:  Defined _ 


The  purpose  of  Process  Definition  and  Maintenance  is  to  establish  the  acquisition  organization’s 
standard  software  acquisition  process  and  an  organizational  responsibility  for  stabilizing  and 
maintaining  the  standard  software  acquisition  process. 

Process  Definition  and  Maintenance  involves  understanding  the  organization’s  and  projects’ 
software  acquisition  processes,  collecting  a  set  of  software  acquisition  process  assets,  and 
coordinating  efforts  to  appraise  and  improve  software  acquisition  processes. 

The  acquisition  organization  provides  the  long-term  commitments  and  resources  to  establish  and 
maintain  a  software  acquisition  process  group.  This  group  is  responsible  for  the  definition, 
maintenance,  and  improvement  of  the  acquisition  organization’s  standard  software  acquisition 
process  and  other  process  assets,  including  guidelines  for  all  projects  to  tailor  the  standard 
software  acquisition  process  to  their  specific  situations.  It  coordinates  process  activities  with  the 
software  projects  and  related  elements  of  the  organization. 

Goals 


Goal  1  A  standard  software  acquisition  process  for  the  acquisition  organization 

is  defined,  managed,  and  controlled. 

Goal  2  Process  definition  and  maintenance  activities  are  coordinated  across  the 

acquisition  organization. 

Goal  3  Information  relating  to  the  use  of  the  acquisition  organization’s  standard 

software  acquisition  process  by  the  software  acquisition  projects  is 
collected,  analyzed,  and  made  accessible. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  software  acquisition 
process  definition  and  maintenance  activities. 

This  policy  typically  specifies  that: 
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Process  Definition  and  Maintenance 


Commitment  2 


Commitment  3 


Ability  1 


1.  A  software  acquisition  process  group  is  established  and  is  responsible  for  the  acquisition 
organization-level  software  acquisition  process  activities  and  coordinating  these  activities 
with  the  projects. 

2.  A  standard  software  acquisition  process  is  defined  for  the  acquisition  organization. 

The  acquisition  organization’s  standard  software  acquisition  process  may  contain  more  than  one 
process.  A  choice  of  processes  may  be  necessary  to  address  a  project’s  unique  acquisition 
environment.  _  _  _  _  _ 


3.  The  software  acquisition  process  used  by  the  projects  is  selected  from  the  acquisition 
organization’s  standard  software  acquisition  process  and  is  tailored  based  on  a  project’s 
specific  acquisition  environment. 

4.  The  software  acquisition  process  assets  are  maintained. 


The  acquisition  organization’s  software  acquisition  process  assets  include: 

the  acquisition  organization’s  standard  software  acquisition  process, 

guidelines  and  criteria  for  the  projects’  tailoring  of  the  acquisition  organization’s  standard 

software  acquisition  process, 

descriptions  of  the  standard  acquisition  strategies  approved  for  use,  and 

the  software  acquisition  process  repository. _ ■ 

5.  Improvements  to,  lessons  learned,  and  other  useful  information  on  each  project’s  defined 
software  acquisition  process,  tools,  and  methods  are  collected  and  made  accessible  to 
other  projects. 

6.  Information  collected  from  the  projects  is  reviewed,  analyzed,  and  used  to  improve  the 
acquisition  organization’s  standard  software  acquisition  process. 

Organization  management  sponsors  the  acquisition  organization’s 
activities  for  process  definition  and  maintenance. 

Organization  management  establishes: 

1.  Long-term  plans  and  commitments  for  funding,  staffing,  and  other  resources,  and  its 
commitment  to  these  software  acquisition  process  activities. 

2.  Strategies  for  managing  and  implementing  the  activities  for  process  definition  and 
maintenance. 

Responsibility  for  process  definition  and  maintenance  activities  is 
designated. 

Ability  to  perform 


A  group  that  is  responsible  for  the  acquisition  organization’s  process 
definition  and  maintenance  activities  exists. 
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Process  Definition  and  Maintenance 


Level  3:  The  Defined  Level 


Ability  2 


Ability  3 


Ability  4 


Activity  1 


Adequate  resources  are  provided  for  process  definition  and  maintenance 
activities. 

Resources  include  funds,  staff,  equipment,  and  tools. 

Members  of  the  software  acquisition  process  group  have  experience  or 
receive  required  training. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition 
management  role  on  at  least  one  project  and  membership  in  an  active  process  group, 
such  as  a  software  engineering  process  group,  for  at  least  one  year. _ 


Project  team  members  receive  training  on  the  acquisition  organization’s 
standard  software  acquisition  process  and  their  roles  in  this  process. 

Refer  to  the  Training  Program  key  process  area. 

Activities  performed 


The  acquisition  organization  performs  its  activities  in  accordance  with  its 
documented  process  definition  and  maintenance  plans. 


The  plan(s)  should  be  consistent  with  other  acquisition  organization  plans.  Inputs, 
such  as  action  plans  from  software  acquisition  process  appraisals,  strategic  and 
operational  business  plans,  and  acquisition  organization  improvement  initiatives, 
should  be  considered  in  the  development  of  and  subsequent  updates  to  the  plan. 


The  plans  typically  cover: 

1.  The  objectives  of  the  acquisition  organization’s  process  definition  and  maintenance 
activities. 


Objectives  define  the  direction  and  general  timing  for  the  acquisition  organization’s  process  definition 
and  maintenance  activities.  Objectives  may  specify  particular  areas  for  improvement  focus,  such  as 
contract  performance  management  and  procedural  guidance  and  the  coverage  and  time  intervals  for 
periodic  appraisals  of  the  software  acquisition  process. _ 

2.  The  process  definition  and  maintenance  activities  to  be  performed  and  the  schedule  for 
these  activities. 

3.  The  groups  and  individuals  responsible  for  the  process  definition  and  maintenance 
activities. 

4.  The  resources  required  to  perform  the  process  definition  and  maintenance  activities. 

5.  The  procedures  to  be  followed  in  performing  the  process  definition  and  maintenance 
activities. 
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Level  3:  The  Defined  Level 


Process  Definition  and  Maintenance 


Activity  2 


Activity  3 


Activity  4 


6.  A  required  review  and  approval  by  acquisition  organization  management. 

7.  Management  and  control  of  the  plan(s). 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

The  acquisition  organization’s  standard  software  acquisition  process  is 
defined  and  maintained  in  accordance  with  its  documented  process 
definition  and  maintenance  plans. 

These  plans  typically  require  that: 

1.  The  acquisition  organization’s  standard  software  acquisition  process  satisfies  the  software 
acquisition  policies,  process  standards,  product  standards,  and  legal  requirements 
imposed  on  the  organization,  as  appropriate. 

2.  State-of-the-practice  software  acquisition  tools  and  methods  are  incorporated  into  the 
acquisition  organization’s  standard  software  acquisition  process,  as  appropriate. 

3.  A  cost  model(s)  for  project  planning  and  estimating  is  developed  and  maintained  as  part 
of  the  acquisition  organization’s  standard  software  acquisition  process. 

The  cost  model(s)  include  a  software  cost  model(s)  for  estimating  the  contractor’s  software  effort, 
schedule,  and  cost;  a  model(s)  for  estimating  the  project  team’s  effort,  schedule,  and  cost;  and  a 
software  cost  model(s)  for  estimating  life  cycle  cost. _ 

4.  The  software  acquisition  process  group  reviews,  approves,  manages,  and  controls  any 
changes  to  the  standard  software  acquisition  process. 

The  acquisition  organization’s  standard  software  acquisition  process  is 
appraised  periodically  and  action  plans  developed  and  implemented  to 
address  the  findings  of  the  appraisal. 

The  action  plans  typically  identify: 

1.  Which  appraisal  findings  will  be  addressed,  their  priority,  and  the  schedule  for  addressing 
them. 

2.  Guidelines  for  implementing  changes  to  address  the  findings. 

3.  Responsibility  for  implementing  the  changes. 

4.  Closure  plans  for  implementing  the  changes. 

5.  Appraisal  findings  that  will  not  be  addressed  and  rationale  for  not  doing  so. 

The  acquisition  organization’s  and  projects’  activities  for  defining  and 
maintaining  their  software  acquisition  processes  are  coordinated  at  the 
organization  level. 
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Level  3:  The  Defined  Level 


Activity  5 


Activity  6 


Guidelines  and  criteria  for  a  project’s  selection  and  tailoring  of  the 
acquisition  organization’s  standard  software  acquisition  process  are 
developed  and  maintained. 

The  guidelines  and  criteria  typically  cover: 

1.  Selecting  and  tailoring  the  acquisition  organization’s  standard  software  acquisition 
process  and  software  acquisition  strategy  to  accommodate  the  project’s  characteristics. 

2.  Standards  for  documenting  the  project’s  defined  software  acquisition  process. 

3.  Procedures  for  obtaining  permission  to  deviate  from  the  acquisition  organization’s 
standard  software  acquisition  process. 

An  organizational  repository  of  software  acquisition  process  information 
is  established,  managed,  controlled,  and  maintained  to  support  process 
definition  and  maintenance  activities. 

1.  Information  includes  data  about  software  the  acquisition  process,  work  products,  software 
acquisition  process-related  documentation,  and  lessons  learned. 


Software  acquisition  process  and  work  products  data  include: 
cost  model  used; 

project  software  measurements  (planned  and  actual);  and 
software  size,  effort,  schedule,  and  deficiencies. _ 

Some  examples  of  software  acquisition  process-related  documentation  include; 

description  of  a  project’s  defined  software  acquisition  process  and 
a  project’s  software  acquisition  documentation  (e.g.,  acquisition  strategy, 
evaluation,  solicitation,  and  software  acquisition  management  plans). _ 

2.  Information  on  the  acquisition  organization’s  and  projects’  software  acquisition  processes 
and  work  products  is  collected. 

3.  Candidate  information  items  are  reviewed  and  appropriate  items  are  included  in  the 
repository. 

4.  Information  items  are  catalogued  for  easy  access. 

5.  The  repository  contents  are  made  available  for  use  by  the  software  acquisition  projects 
and  other  software  acquisition-related  groups. 

6.  The  use  of  each  information  item  is  reviewed  periodically  for  currency,  relevancy,  and 
validity,  and  the  results  are  used  to  maintain  the  repository  contents. 

7.  User  access  to  the  repository  contents  is  controlled  to  ensure  completeness,  integrity,  and 
accuracy  of  the  information. 

8.  Access  is  limited  to  those  who  have  a  need  to  enter,  change,  view,  analyze,  or  extract 
information.  Sensitive  information  is  protected  and  access  to  this  information  is 
appropriately  controlled. 
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Process  Definition  and  Maintenance 


Activity  7 


Measurement  1 


Verification  1 


Project  teams  are  informed  of  the  acquisition  organization’s  activities  for 
process  definition  and  maintenance  and  of  the  projects’  tailoring  of  the 
acquisition  organization’s  standard  software  acquisition  process. 

Some  examples  of  means  to  inform  project  teams  include: 

electronic  bulletin  boards  relating  to  software  acquisition 

process, 

working  groups, 

information  exchange  meetings, 

surveys, 

process  improvement  teams,  and 
informal  discussions. 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  process 
definition  and  maintenance  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  process  definition  and  maintenance 
planning,  defining  the  acquisition  organization’s  standard  software 
acquisition  process,  defining  guidelines  for  tailoring  the  standard  software 
acquisition  process,  establishing  the  standard  software  acquisition, 
repository,  and  establishing  vehicles  for  disseminating  software 
acquisition  information;  and 

completion  of  milestones. _ 


Verifying  implementation 


Process  definition  and  maintenance  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  process  definition  and  maintenance  activities 
at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 


At  a  minimum,  these  reviews  verify  that: 

1.  Progress  and  status  of  the  activities  to  define  and  improve  the  software  acquisition 
process  are  reviewed  against  the  plan. 
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2.  Conflicts  and  issues  not  resolved  at  lower  levels  are  addressed. 

3.  Action  items  are  assigned,  reviewed,  and  tracked  to  closure. 

4.  A  summary  report  from  each  review  is  prepared  and  distributed  to  affected  groups  and 
individuals. 
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Project  Performance  Management 

a  key  process  area  for  Level  3:  Defined 


The  purpose  of  Project  Performance  Management  is  to  manage  the  software  acquisition  project 
according  to  a  defined  software  acquisition  process. 

Project  Performance  Management  involves  developing  the  project’s  defined  software  acquisition 
process  and  managing  the  acquisition  using  this  defined  process.  The  project’s  defined  software 
acquisition  process  is  tailored  from  the  acquisition  organization’s  standard  software  acquisition 
process  to  address  specific  attributes  of  the  project. 

The  project’s  management  plans  are  based  on  the  project’s  defined  software  acquisition  process. 
These  plans  describe  how  the  project’s  defined  software  acquisition  process  will  be  implemented 
and  managed. 

The  basic  requirements  for  estimating,  planning,  and  tracking  a  software  acquisition  project  are 
established  in  the  Software  Acquisition  Planning,  Project  Management,  and  Contract  Tracking 
and  Oversight  key  process  areas.  The  emphasis  in  Project  Performance  Management  at  Level  3 
shifts  from  reacting  to  acquisition  problems  and  issues  to  anticipating  these  problems  and  acting 
to  mitigate  the  risk. 

Goals 


Goal  1  The  project  is  managed  according  to  a  defined  software  acquisition 

process  which  is  tailored  from  the  acquisition  organization’s  standard 
software  acquisition  process. 

Goal  2  The  project  team  achieves  its  software  acquisition  objectives. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  planning  and 
managing  of  the  project’s  software  acquisition  activities. 

This  policy  typically  specifies  that: 

1 .  The  project’s  defined  software  acquisition  process  is  developed  and  documented  by 

tailoring  the  acquisition  organization’s  standard  software  acquisition  process  according  to 
approved  tailoring  guidelines. 
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Project  Performance  Management 


Level  3:  The  Defined  Level 


Ability  1 


Activity  1 


Activity  2 


Refer  to  Activity  5  of  the  Process  Definition  and  Maintenance  key  process  area. 

2.  The  project’s  software  acquisition  activities  are  planned  and  performed  according  to  the 
project’s  defined  software  acquisition  process. 

3.  Appropriate  project  measurement  data  are  collected  and  stored  by  the  project  team 
according  to  the  acquisition  organization’s  software  acquisition  process  repository 
requirements. 

Ability  to  perform 


The  individuals  responsible  for  managing  the  software  acquisition  project 
activities  have  experience  or  receive  required  training. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition 
management  role  on  at  least  one  project  and  having  experience  in  the  domain  of  the 
application  being  acquired.  Additionally,  some  individuals  should  have  experience 
in  project  planning,  organizing,  controlling,  budgeting,  and  scheduling. _ 


Activities  performed 


The  project’s  defined  software  acquisition  process  is  developed  and 
documented  by  tailoring  the  acquisition  organization’s  standard  software 
acquisition  process  according  to  the  organization’s  tailoring  guidelines. 

Refer  to  Activity  5  of  the  Process  Definition  and  Maintenance  key  process  area. 

The  project  team  develops  and  maintains  the  Project  Management  Plan 
in  accordance  with  the  acquisition  organization’s  standard  software 
acquisition  process. 

Refer  to  the  Software  Acquisition  Planning,  Project  Management,  and  Contract  Tracking  and 
Oversight  key  process  areas. 

The  Project  Management  Plan  typically  addresses: 

1.  Management  of  solicitation  and  proposal  evaluation  plans. 

2.  Management  of  transition  to  support  plans. 

3.  Provisions  for  gathering,  analyzing,  and  reporting  measurement  data  needed  to  manage 
the  software  acquisition  project. 

4.  Activities  for  software  estimating,  planning,  and  tracking  related  to  the  key  tasks  and 
work  products  of  the  project’s  defined  software  acquisition  process. 
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Project  Performance  Management 


Activity  3 

Activity  4 
Activity  5 
Activity  6 


5.  Readiness  and  completion  criteria  established,  documented,  and  used  to  authorize 
initiation  and  determine  completion  of  key  tasks. 

6.  Critical  dependencies  and  paths  that  are  to  be  reflected  in  the  schedule  and  tracked  on  a 
regular  basis. 

7.  Documented  criteria  indicating  when  to  review  and  revise  the  Project  Management  Plan. 

8.  Review  and  use  of  software  acquisition  management  lessons  learned,  recorded,  and  stored 
in  the  acquisition  organization’s  software  acquisition  process  repository  to  estimate,  plan, 
track,  and  re-plan  the  software  acquisition  project. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

9.  A  staffing  plan  that  addresses  the  software  acquisition  project’s  needs  for  individuals  with 
special  skills  and  acquisition  domain  knowledge. 

10.  Training  needs  identified  and  documented  to  fit  the  specific  needs  of  the  software 
acquisition  project. 

Refer  to  the  Training  Program  key  process  area. 

11.  Software  acquisition  management  plans  and  processes  to  be  followed  in  interacting  with 
other  groups. 

12.  Risk  management  planning. 

Refer  to  Activity  2  of  the  Acquisition  Risk  Management  key  process  area. 

13.  Resources  to  accomplish  the  requirements  of  the  Project  Management  Plan. 

14.  Management  of  both  organizational  and  technical  interfaces. 

15.  Tailoring  of  the  acquisition  organization’s  standard  software  acquisition  process. 

The  project  team’s  software  acquisition  management  activities  are 
performed  in  accordance  with  the  project’s  defined  software  acquisition 
process  and  the  Project  Management  Plan. 

The  project’s  defined  software  acquisition  process  is  revised  as  required 
to  remain  consistent  with  current  project  objectives. 

The  project  team  coordinates  its  activities  with  other  organizations  and 
activities  supporting  the  project 

The  acquisition  organization’s  software  acquisition  process  repository  is 
used  for  project  planning,  estimating,  and  management. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 
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Level  3:  The  Defined  Level 


Activity  7 
Activity  8 

Activity  9 

Activity  10 

Activity  11 


Measurement  1 


Verification  1 


Critical  dependencies  are  identified,  negotiated,  and  managed. 

The  project  team  performs  periodic  reviews  to  ensure  current  and 
projected  needs  of  the  end  user  will  be  satisfied. 

Measurements  are  used  to  determine  project  team  performance  and 
trends  analyzed. 


Trend  analysis  relies  on  internal  and  external  data. 

The  project  team  identifies  and  analyzes  risks  and  identifies  specific  risk 
mitigation  actions  for  those  risks. 

Refer  to  Activity  3  of  Software  Acquisition  Planning,  Activity  1  of  Contract  Performance 
Management,  and  Activity  5  of  Acquisition  Risk  Management  key  process  areas. 

The  project  team’s  software  acquisition  lessons  learned  are  identified, 
documented,  and  entered  into  the  acquisition  organization’s  software 
acquisition  process  repository. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  project 
performance  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  the  Project  Management  Plan, 
updates  to  the  Project  Management  Plan,  establishing  a  corrective 
action  system,  and  updating  the  software  acquisition  process 
repository;  and 

completion  of  milestones. _ 


Verifying  implementation 


Project  performance  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 
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Project  Performance  Management 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  project  performance  management  activities  at 
an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Verification  2  Project  performance  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 


Contract  Performance  Management 


Level  3:  The  Defined  Level 


Contract  Performance  Management 

a  key  process  area  for  Level  3:  Defined 


The  purpose  of  Contract  Performance  Management  is  to  implement  a  defined  contract 
management  process,  the  objective  of  which  is  to  acquire  software  products  and  services  that 
satisfy  contract  requirements. 

Contract  Performance  Management  involves  appraising  the  contractor  team’s  software 
engineering  performance  and  the  quality  of  the  evolving  products  and  ongoing  services.  Based 
on  the  results  of  the  appraisals,  the  acquisition  may  be  adjusted.  The  process  includes  evaluation 
of  final  products  and  services  to  determine  satisfaction  of  contractual  requirements.  The 
emphasis  in  contract  performance  management  is  to  be  proactive  regarding  contractor  team 
performance  and  contract  compliance  issues  and  to  minimize  the  effects  of  these  issues. 
Additional  activities  include  contributing  to  the  project’s  risk  management  activities,  fostering  an 
environment  of  mutual  cooperation  with  the  contractor,  and  identifying  improvements  to  the 
contract  performance  management  process. 

The  contract  performance  management  process  integrates  contract  performance  management 
activities  with  other  project  management  activities.  Contract  Performance  Management  builds 
on  the  Contract  Tracking  and  Oversight  and  Evaluation  key  process  areas.  Contract  performance 
management  begins  when  the  contract  is  awarded  and  ends  at  the  conclusion  of  the  contract’s 
period  of  performance. 


Goals 


Goal  1  The  quality  of  contractor  team  process,  performance,  products,  and 

services  is  appraised  throughout  the  contract’s  period  of  performance  to 
identify  risks  and  take  action  to  mitigate  those  risks  as  early  as  possible. 

Goal  2  Contract  Performance  Management  activities  intended  to  foster  a 

cooperative  and  productive  environment  among  the  end  user,  project 
team,  and  the  contractor  team  are  implemented. 


Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  performance  of 
contract  performance  management  activities. 


L3-14 


CMU/SEI-99-TR-002 


Level  3:  The  Defined  Level 


Contract  Performance  Management 


Ability  1 


Activity  1 


This  policy  typically  specifies  that: 

1.  Contract  performance  management  activities  are  performed  in  accordance  with  the 
project’s  defined  software  acquisition  process. 

2.  Appropriate  tools  and  methodologies  are  used  to  evaluate  the  products  and  services. 

3.  Risk  analysis  and  management  are  included  as  part  of  the  contract  performance 
management  activities. 

4.  Software  products  and  services  must  pass  a  successful  evaluation  of  contract  requirements 
before  they  are  accepted. 

5.  Software  acceptance  is  dependent  on  the  successful  completion  of  operational  evaluation. 

6.  Evaluation  requirements  and  measurable  acceptance  criteria  are  established  before  the 
request  for  proposals  is  released. 

7.  The  contractor  is  encouraged  to  establish  a  rigorous  engineering  evaluation  process. 

8.  The  project’s  software  evaluation  planning  is  updated  to  reflect  changes  to  the 
requirements. 

Ability  to  perform 


Individuals  performing  contract  performance  management  activities  have 
experience  or  receive  required  training  in  related  software  acquisition 
disciplines  and  contract  performance  management  procedures. 


Experience  means,  for  example,  having  participated  on  more  than  one  software 
development  project  including  appraising  the  contractor's  planning  documents, 
software  engineering  process,  products,  and  services;  having  knowledge  of  current 
software  development  technologies;  and  having  knowledge  in  the  domain  of  the 
application  being  acquired. _ 


Training  includes  areas  of  software  evaluation,  data  reduction,  and  analysis 
techniques. _ 


Activities  performed 


The  project  team  performs  its  activities  in  accordance  with  its 
documented  contract  performance  management  plans. 

In  addition  to  the  planning  information  called  for  in  the  Contract  Tracking  and  Oversight  key 
process  area,  these  plans  also  typically  cover: 
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Activity  2 


Activity  3 


1 .  The  guidelines  and  criteria  used  in  defining  the  project’s  contract  performance 
management  activities. 

2.  The  activities  to  be  performed  and  the  schedule  to  perform  the  activities. 

3.  Risk  management. 

Refer  to  Activity  3  of  Software  Acquisition  Planning  and  Activity  1  of  the  Contract  Tracking 

and  Oversight  key  process  areas. 

The  contractor  team’s  software  engineering  process  is  appraised 
according  to  the  project’s  defined  software  acquisition  process. 

Typical  activities  include: 

1.  The  contractor  team’s  software  engineering  process,  practices,  methodologies,  and 
procedures  are  continually  appraised  for  effectiveness  and  for  compliance  with 
contractual  requirements. 

2.  The  contractor’s  quality  assurance,  configuration  management,  corrective  action,  and  risk 
management  systems  and  processes  are  appraised  for  compliance  with  standards  and 
plans  to  ensure  that  associated  results  support/promote  attainment  of  contract  objectives 
and  compliance  with  contractual  requirements. 

3.  Trend  analysis  of  the  contractor  team’s  software  engineering  process  is  performed  to 
detect  issues  in  satisfying  contractual  requirements  as  early  as  possible. 

Results  of  the  contractor  team’s  engineering  activities  are  appraised 
according  to  the  project’s  defined  software  acquisition  process. 

Appraisals  conducted  typically  verify  that: 

1.  The  software  requirements  are  being  developed,  documented,  maintained,  and  verified 
according  to  the  contractor  team’s  software  engineering  process  and  are  traceable  to 
higher  level  requirements. 

2.  The  software  architecture  is  feasible  and  will  satisfy  future  system  growth  and  reuse 
needs. 

3.  The  software  design  is  developed,  documented,  maintained,  and  verified  according  to  the 
contractor’s  software  engineering  process. 

4.  The  software  is  developed  and  documented  according  to  the  contractor’s  software 
engineering  process. 

5.  The  documentation  that  will  be  used  to  operate  and  support  the  software  is  developed  and 
maintained  according  to  the  contractor’s  software  engineering  process. 

6.  The  integration  of  commercial  off-the-shelf  (COTS)  products  with  developed  software  is 
accomplished  in  accordance  with  the  contractor’s  software  engineering  process  and 
planning  documents. 
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Contract  Performance  Management 


Activity  4 


Activity  5 


Activity  6 


Activity  7 


Measurements  from  appraisals  are  used  to  evaluate  the  contractor  team’s 
performance  and  trends  analyzed. 

|  Trend  analysis  can  rely  on  internal  and  external  data. 


As  understanding  of  the  contractor  team’s  software  engineering  process, 
products,  and  services  improves,  the  project  team  may  propose  changes 
to  the  software  acquisition  approach  to  mitigate  risks, 

1.  The  project  team  determines  the  impact  of  changes  before  the  changes  are  implemented. 

2.  Changes  to  the  acquisition  approach  are  coordinated  within  the  project  team  and 
communicated  to  other  affected  groups. 

3.  Adjustments  that  affect  contractual  requirements  are  made  through  official  contracting 
channels. 

The  end  user  periodically  participates  in  the  evaluation  of  evolving 
software  products  and  services  to  determine  the  satisfaction  of 
operational  requirements. 

Refer  to  Activity  5  of  the  Evaluation  key  process  area. 

Contract  performance  management  activities  are  performed  to  foster  a 
cooperative  and  productive  environment  among  the  end  user,  project 
team,  and  the  contractor  team. 

Typical  activities  include: 

1 .  Supporting  a  mutual  understanding  of  the  contract’s  requirements  (and  their  flow  down) 
between  the  project  team  and  the  contractor  team. 

2.  Maintaining  ongoing  communications  between  the  project  team  and  the  contractor  team  at 
appropriate  levels. 

3.  Allowing  the  contractor  to  manage  the  software  engineering  efforts  for  which  it  is 
responsible,  including  engineering  evaluation,  with  minimal  project  team  interference. 

4.  Promoting  the  joint  development  of  solutions  to  issues  by  the  project  team  and  the 
contractor  team. 

5.  Requiring  that  the  project  team  satisfies  its  commitments  to  the  contractor  team,  such  as 
review  of  contractor-generated  documentation  and  timely  feedback  of  the  results  of 
project  team  evaluations  of  contractor  team’s  performance,  products,  and  services. 

6.  Maintaining  mutual  understanding  of  methods  to  administer  the  contract. 


CMU/SEI-99-TR-002 


L3-17 


Contract  Performance  Management 


Level  3:  The  Defined  Level 


Measurement  1 


Verification  1 


Verification  2 


Some  examples  of  areas  to  be  addressed  include: 

maintenance  of  bi-directional,  non-intrusive  communications  between  the  project  team  and  the 
contractor  team; 

how  issues  and  concerns  not  resolvable  at  lower  levels  will  be  decided; 
methods  of  identifying  and  mitigating  risks;  and 

the  use  of  both  software  process  and  product  measurements  as  a  common  basis  of  communication  to 
understand  the  requirements  and  the  status  of  the  project. _ 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  contract 
performance  management  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  contract  performance 
management  planning,  appraisals,  evaluations,  and  risk 
analysis;  and 

completion  of  milestones. _ 


Verifying  implementation 


Contract  performance  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  contract  performance  management  activities 
at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 


Contract  performance  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 


L3-18 


CMU/SEI-99-TR-002 


Level  3:  The  Defined  Level 
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Acquisition  Risk  Management 

a  key  process  area  for  Level  3:  Defined 


The  purpose  of  Acquisition  Risk  Management  is  to  identify  risks  as  early  as  possible,  adjust  the 
acquisition  strategy  to  manage  those  risks,  and  develop  and  implement  a  risk  management 
process  as  an  integral  part  of  the  acquisition  organization’s  standard  software  acquisition  process. 
Acquisition  risk  management  begins  with  the  process  of  defining  the  system  need  and  terminates 
when  the  software  acquisition  is  completed.  Acquisition  risk  management  becomes  an  integral 
part  of  the  solicitation,  project  performance  management,  and  contract  performance  management 
processes. 

Acquisition  risk  management  is  a  two-part  process.  First,  the  software  acquisition  strategy 
identifies  the  risks  associated  with  the  acquisition  of  the  system  and  the  approach  is  planned 
based  on  those  risks.  Second,  a  process  is  employed  to  manage  the  risks  throughout  the 
acquisition. 

Risk  identification  includes  categorization  of  the  risk  based  on  historical  data  and  estimates  to 
determine  the  impact  of  each  risk  on  quality,  performance,  schedule,  and  cost.  The  risks  are 
analyzed  to  determine  their  impact  on  acquisition  strategy  and  software  engineering.  Analysis 
includes  determining  the  driver  of  each  risk  area  and  the  impact  of  the  risk  so  that  risk  handling 
strategies  may  be  proposed  and  tested. 

Acquisition  risk  management  is  planned  through  the  Software  Acquisition  Risk  Management 
Plan  which  details  the  processes  to  take  place  in  acquisition  planning  and  software  acquisition 
management.  The  Software  Acquisition  Risk  Management  Plan  describes  the  management 
actions  and  procedures  to  identify,  analyze,  and  rank  order  risks,  and  the  risk  handling  methods 
to  be  applied. 


Goals 


Goal  1  Project-wide  participation  in  the  identification  and  mitigation  of  risks  is 

encouraged  and  rewarded. 

Goal  2  The  project  team’s  defined  software  acquisition  process  provides  for  the 

identification,  analysis,  and  mitigation  of  risks  for  all  project  functions. 

Goal  3  Project  reviews  include  the  status  of  identified  risks. 
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Commitment  1 


Commitment  2 

Ability  1 
Ability  2 

Ability  3 

Activity  1 


Commitment  to  perform 


The  acquisition  organization  has  a  written  policy  for  the  management  of 
software  acquisition  risk. 

This  policy  typically  specifies  that: 

1.  Risk  identification  is  performed  throughout  the  project  life  cycle  in  accordance  with  the 
project’s  defined  software  acquisition  process. 

2.  Risk  management  activities  involve  the  project  team,  end  user,  and  the  contractor  team  as 
appropriate. 

3.  Risk  management  is  a  positive  and  proactive  part  of  software  acquisition. 

4.  Risk  information  is  communicated  throughout  the  project  team. 

Responsibility  for  software  acquisition  risk  management  activities  is 
designated. 

Ability  to  perform 


A  group  that  is  responsible  for  coordinating  software  acquisition  risk 
management  activities  exists. 

Adequate  resources  are  provided  for  software  acquisition  risk 
management  activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Individuals  performing  software  acquisition  risk  management  activities 
have  experience  or  receive  required  training. 

Experience  means,  for  example,  having  participated  in  a  software  acquisition 
management  role  and  having  applied  risk  management  techniques  on  at  least  one 
project  and  having  experience  in  the  domain  of  the  application  being  acquired. _ 

Activities  performed 


Software  acquisition  risk  management  activities  are  integrated  into 
software  acquisition  planning. 
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Acquisition  Risk  Management 


Activity  2 


Activity  3 
Activity  4 

Activity  5 

Activity  6 


Risk  management  includes  risk  identification,  analysis,  planning,  tracking,  and 
controlling. _ 


The  acquisition  strategy  evolves  based  on  risk  identification  and 
analysis. _ 


Refer  to  Activity  3  of  the  Software  Acquisition  Planning  key  process  area. 

The  Software  Acquisition  Risk  Management  Plan  is  developed  in 
accordance  with  the  project’s  defined  software  acquisition  process. 

The  plan  typically  provides  for: 

1 .  The  processes  that  the  project  team  will  follow  for  risk  management. 

2.  Reporting  on  risk  management  activities. 

3.  Plans  for  identification,  analysis,  and  mitigation  of  risks. 

4.  The  process  for  managing  and  controlling  the  Software  Acquisition  Risk  Management 
Plan. 

5.  Resource  requirements. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 

The  project  team  performs  its  software  acquisition  risk  management 
activities  in  accordance  with  its  documented  plans. 

The  project  team  encourages  and  rewards  project-wide  participation  in 
the  identification  and  mitigation  of  risks. 

1.  Mitigation  plans  and  decisions  are  predicated  upon  key  project  milestones. 

2.  Risks  are  presented,  discussed,  and  action  taken  in  a  non-threatening  environment. 

3.  Where  appropriate,  research  on  individual  risks  is  authorized  and  encouraged. 

Risk  management  is  conducted  as  an  integral  part  of  the  solicitation, 
project  performance  management,  and  contract  performance 
management  processes. 

Refer  to  Activity  1  of  Solicitation,  Activities  2  and  10  of  Project  Performance  Management, 
and  Activities  1  and  2  of  the  Contract  Performance  Management  key  process  areas. 

Software  acquisition  risks  are  analyzed,  tracked,  and  controlled  until 
mitigated. 

These  actions  typically  include: 
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Level  3:  The  Defined  Level 


Activity  7 


Measurement  1 


Verification  1 


1 .  Tracking  the  status  of  the  risks  and  planned  mitigations. 

2.  Reporting  of  the  updated  risk  assessments. 

3.  Planned  mitigation  actions  are  maintained  current. 

Project  reviews  include  the  status  of  identified  risks. 

Items  reported  typically  include: 

1.  Changes  in  the  priority  of  risks. 

2.  Changes  in  mitigation  plans. 

3.  New  risks  identified. 

Refer  to  Activity  10  of  the  Project  Performance  Management  key  process  area. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
acquisition  risk  management  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

status  of  development  of  the  Software  Acquisition  Risk  Management 
Plan, 

status  of  risks  (e.g.,  top  ten  list), 
status  of  risk  management  actions,  and 

status  of  the  of  risk  management  analysis  actions. _ 


Verifying  implementation 


Acquisition  risk  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  acquisition  risk  management  activities  at  an 
appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 
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Acquisition  Risk  Management 


Verification  2  Acquisition  risk  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 


Training  Program 


Level  3:  The  Defined  Level 


Training  Program _ 

a  key  process  area  for  Level  3:  Defined 


The  purpose  of  Training  Program  is  to  develop  the  skills  and  knowledge  of  individuals  so  they 
can  perform  their  software  acquisition  roles  effectively  and  efficiently. 

Training  Program  involves  appraisal  of  training  requirements  at  the  acquisition  organization, 
project,  and  individual  levels.  The  acquisition  organization  surveys  its  current  and  future  skill 
needs  and  determines  how  these  skills  will  be  obtained.  Current  weaknesses  of  the  acquisition 
organization  are  understood  and  plans  are  developed  to  systematically  address  the  weaknesses. 

Some  skills  are  effectively  and  efficiently  imparted  through  informal  vehicles,  whereas  other 
skills  need  more  formal  training  vehicles  to  be  effectively  and  efficiently  imparted.  The 
appropriate  vehicles  are  selected  and  used. 

Members  of  the  acquisition  organization  are  schooled  in  the  standard  software  acquisition 
process,  the  project,  the  domain,  and  in  the  skills  and  knowledge  needed  to  perform  their  jobs 
effectively.  Members  effectively  use,  or  are  prepared  to  use,  the  capabilities  and  features  of  the 
existing  and  planned  work  environment.  The  project  teams  become  more  effective  through  a 
better  understanding  of  their  work  processes. 

This  key  process  area  covers  the  group  that  is  performing  the  organization’s  training  function. 
The  processes  identifying  specific  training  topics  (e.g.,  knowledge  or  skills  needed)  are  contained 
in  the  common  feature  “Ability  to  perform”  of  the  individual  key  process  areas. 

Goals 


Goal  1  Training  required  for  the  projects  to  achieve  their  software  acquisition 

objectives  is  identified  and  provided. 

Goal  2  The  training  program  satisfies  the  acquisition  organization’s  training 

needs,  including  training  on  the  standard  software  acquisition  process. 

Commitment  to  perform 


Commitment  1  The  organization  has  a  written  policy  for  satisfying  its  training  needs. 

This  policy  typically  specifies  that: 
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Training  Program 


Commitment  2 


Ability  1 


AbUity  2 


1.  The  needed  skills,  knowledge,  and  abilities  are  identified  for  each  software  acquisition 
managerial  and  technical  role  within  this  model. 

2.  The  training  program  is  developed  to  build  the  skill  base  of  the  organization,  to  fill  the 
specific  needs  of  the  projects,  and  to  develop  the  skills  of  individuals. 

3.  Training  is  provided  from  within  the  acquisition  organization  or  obtained  from  outside  the 
acquisition  organization  when  appropriate. 


Some  examples  of  external  training  sources  include: 

end  user-provided  training, 
commercially  available  training  courses, 
academic  programs, 
professional  conferences,  and 
seminars. 


4.  Training  vehicles  for  imparting  skills  and  knowledge  are  identified,  approved,  and 
managed. 


Some  examples  of  training  vehicles  include: 

classroom  training, 
computer-aided  instruction, 
guided  self-study, 

formal  apprenticeship  and  mentoring  programs,  and 
facilitated  videos.  _  _ 


Responsibility  for  implementing  the  organization’s  training  program  is 
designated. 

Ability  to  perform 


A  group  that  is  responsible  for  fulfilling  the  training  needs  of  the 
organization  exists. 


The  members  of  the  training  group  may  include  full-time  or  part-time  instructors 
drawn  from  the  organization  and  from  external  sources. _ 


Adequate  resources  are  provided  for  training  program  activities. 

1.  Resources  include  funding,  staff,  equipment,  and  tools. 

2.  Appropriate  facilities  are  made  available  to  conduct  training. 

►  Classroom  training  facilities  should  be  separated  from  the  students’  work 
environments  to  minimize  interruptions. 

►  Where  appropriate,  training  is  conducted  in  settings  that  closely  resemble  actual 
performance  conditions  and  includes  activities  to  simulate  actual  work  situations. 
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Level  3:  The  Defined  Level 


Ability  3 


Ability  4 


Activity  1 


Members  of  the  training  group  have  the  necessary  skills  and  knowledge 
to  perform  their  training  activities. 


Some  examples  of  ways  to  provide  these  skills  and  knowledge 
include: 

training  in  instructional  techniques  and 

refresher  training  in  the  subject  matter. _ 


Software  acquisition  management  personnel  receive  orientation  on  the 
training  program. 

Some  examples  of  topics  for  orientation  include: 

corporate  training  program  objectives  and 
plan, 

process  for  determination  of  training  needs, 
methods  for  providing  required  training,  and 
identification  of  training  sources. _ 


Activities  performed 


The  organization’s  training  program  is  planned,  developed,  implemented, 
and  maintained  to  support  the  organization’s  training  requirements. 


Some  examples  of  training  program  elements 
include: 

the  organization’s  training  plan, 
training  materials, 

development  or  procurement  of  training, 

conduct  of  training, 

training  facilities, 

appraisal  of  training,  and 

maintaining  training  records. _ 


The  organization’s  training  program  typically  covers: 

1.  Training  senior  management  in  the  technologies  and  strategies  that  are  being  used  for 
acquisition  management. 

2.  The  set  of  skills  needed  and  when  those  skills  are  needed. 

3.  Training  that  is  required,  for  whom  it  is  required,  and  when  it  is  required. 

Training  for  individuals  is  tied  to  their  work  responsibilities  such  that  on-the-job  activities  or  outside 
experience  will  reinforce  the  training  within  a  reasonable  time  after  receiving  the  training. _ 
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Training  Program 


Activity  2 


Activity  3 
Activity  4 


Activity  5 


4.  Developing  individual  training  plans. 

5.  How  training  will  be  provided. 


The  training  may  be  provided  by  the  project,  by  the  organization’s  training  program,  or  by  an  external 
group. _ 


Each  software  acquisition  project  identifies  specific  training  needs  and 
develops  a  training  plan  in  accordance  with  training  program 
procedures. 

The  project’s  training  plan  typically  covers: 

1.  The  set  of  skills  needed  and  when  those  skills  are  needed. 

2.  Skills  for  which  training  is  required  and  the  skills  that  will  be  obtained  via  other  vehicles. 

3.  Training  that  is  required,  for  whom  it  is  required,  and  when  it  is  required. 

Training  for  individuals  is  tied  to  their  work  responsibilities  such  that  on-the-job  activities  or  outside 
experience  will  reinforce  the  training  within  a  reasonable  time  after  receiving  the  training. _ 

4.  How  training  will  be  provided  with  a  breakdown  of  resources  required  to  provide  this 
training. 


The  training  may  be  provided  by  the  project,  by  the  organization’s  training  program,  or  by  an  external 

grcMP- _ 

5.  The  requirement  that  the  software  acquisition  project’s  training  plans  undergo  a  peer 
review. 

Refer  to  Activity  4  of  the  Software  Acquisition  Planning  key  process  area. 


t 

Software  acquisition  training  for  the  organization  is  provided  in 
accordance  with  the  organization’s  training  program. 

A  waiver  procedure  for  required  training  is  established  and  used  to 
determine  whether  individuals  already  possess  the  knowledge  and  skills 
required  to  perform  their  designated  roles. 

Training  records  are  maintained. 

Some  of  the  records  to  be  maintained  are: 

1.  All  students  who  successfully  complete  each  training  course  or  other  approved  training 
activity. 

2.  All  students  who  successfully  complete  their  designated  required  training  as  specified  in 
their  training  plan. 

3.  Successfully  completed  training. 
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Training  Program 


Level  3:  The  Defined  Level 


Activity  6 


Measurement  1 


Verification  1 


Measurements  are  used  to  determine  the  quality  of  the  training  program. 


Some  examples  of  measurements  include: 

reviews  of  the  courses  from  the  students, 
reviews  of  the  class  from  the  instructor,  and 
feedback  from  the  software  managers. 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the  training 
program  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  training  program 
planning,  projects’  training  plans,  and  training 
records; 

completion  of  milestones;  and  cost  of  the  training 
program. _ 


Verifying  implementation 


Training  program  activities  are  reviewed  by  organization  management 
on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  organization  management  is  to  provide 
awareness  of,  and  insight  into,  training  program  activities  at  an  appropriate  level  of 
abstraction.  The  reviews  verify  that  organization  policy  is  being  implemented.  The 
time  between  reviews  should  satisfy  the  needs  of  the  organization  and  may  be 
lengthy,  as  long  as  adequate  mechanisms  for  exception  reporting  are  available. 
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Level  4  -  The  Quantitative  Level 


At  the  Quantitative  Level,  the  project  team  sets  quantitative  quality  objectives  for  processes, 
products,  and  services.  A  process  is  established  to  provide  a  quantitative  foundation  for 
evaluating  project  processes,  products,  and  services. 

Project  teams  achieve  control  over  acquisition  processes,  products,  and  services  by  narrowing  the 
variation  in  project  performance  to  within  acceptable  quantitative  boundaries.  Data  on  the 
defined  software  acquisition  process  and  variations  outside  the  acceptable  quantitative 
boundaries  are  used  to  adjust  the  process  to  prevent  recurrence  of  deficiencies.  An  acquisition 
organization-wide  process  repository  provides  for  the  collection  and  analysis  of  data  from  the 
projects’  defined  software  acquisition  processes. 

The  process  capability  of  Level  4  acquisition  organizations  can  be  summarized  as  measured  and 
operating  within  measurable  limits.  This  level  of  process  capability  allows  an  organization  to 
predict  process  and  product  quality  trends  within  the  quantitative  bounds  of  these  limits.  When 
these  limits  are  exceeded,  action  is  taken  to  correct  the  situation. 

Level  4  key  process  areas  are: 

Quantitative  Process  Management 
Quantitative  Acquisition  Management 
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Level  4:  The  Quantitative  Level 


Quantitative  Process  Management 

a  key  process  area  for  Level  4:  Quantitative 


The  purpose  of  Quantitative  Process  Management  is  to  quantitatively  control  the  project’s 
performance  resulting  from  implementation  of  the  software  acquisition  process.  Projects  fully 
implementing  quantitative  process  management  will  have  stable  processes  that  are  under 
quantitative  control.  Additionally,  the  capability  of  the  acquisition  organization’s  standard 
software  acquisition  process  is  defined  quantitatively. 

Quantitative  Process  Management  involves  each  project  team  setting  performance  objectives, 
measuring  performance,  analyzing  results,  and  making  adjustments  to  maintain  performance 
within  acceptable  limits.  Performance  variations  (i.e.,  variations  attributable  to  specific 
implementations  of  the  process)  are  measured  and  actions  taken  to  bring  performance  within 
acceptable  limits.  When  the  project  team’s  performance  is  stabilized  within  acceptable  limits, 
the  defined  software  acquisition  process,  the  associated  measurements,  and  the  acceptable 
performance  limits  are  baselined  to  permit  quantitative  control  of  the  project  team’s  performance. 

The  acquisition  organization  collects  performance  data  from  the  software  acquisition  projects  and 
uses  these  data  to  define  the  capability  of  its  standard  software  acquisition  process  (see  the 
Process  Definition  and  Maintenance  key  process  area).  The  capability  of  the  acquisition 
organization’s  standard  software  acquisition  process  is  indicative  of  the  performance  that  can  be 
expected  from  the  next  software  acquisition  project  undertaken.  These  capability  data  are,  in 
turn,  used  by  the  software  acquisition  project  teams  to  set  their  performance  objectives  and  to 
analyze  the  performance  of  their  defined  software  acquisition  processes.  The  capability  data  are 
also  used  by  the  project  teams  in  tailoring  the  acquisition  organization’s  standard  software 
acquisition  process  to  a  particular  acquisition. 

Goals 


Goal  1  The  performance  of  each  project  is  quantitatively  measured,  managed, 

and  controlled. 

Goal  2  The  capability  of  the  acquisition  organization’s  standard  software 

acquisition  process  is  analyzed  and  defined  in  quantitative  terms. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  the  measurement 
and  quantitative  control  of  software  acquisition  process  performance. 
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Quantitative  Process  Management 


Commitment  2 


Ability  1 


The  term  “quantitative  control”  implies  any  quantitative  or  statistically-based 
technique  appropriate  for  analyzing  a  software  acquisition  process,  identifying  causes 
of  process  performance  variations,  and  adjusting  the  process  to  bring  performance 
within  prescribed  limits. _ 


This  policy  typically  specifies  that: 

1 .  Each  project  team  plans  and  implements  quantitative  control  of  its  defined  software 
acquisition  process. 

2.  Access  to  sensitive  data  is  appropriately  controlled. 

The  acquisition  organization  has  a  written  policy  for  analysis  of  the 
capability  of  its  standard  software  acquisition  process. 

This  policy  typically  specifies  that: 

1.  Each  project  team’s  measurements  of  process  performance  are  analyzed  to  establish  and 
maintain  a  process  capability  baseline  for  the  acquisition  organization’s  standard  software 
acquisition  process. 

►  The  process  capability  baseline  includes: 

*  The  description  of  the  acquisition  organization’s  standard  software  acquisition 
process. 

*  The  standard  definitions  of  the  measurements. 

*  The  expected  range  of  values  for  the  measurements. 

2.  The  acquisition  organization’s  software  acquisition  process  capability  baseline  is  used  by 
each  project  team  in  establishing  its  process  performance  objectives. 

Ability  to  perform 


Adequate  resources  are  provided  for  quantitative  process  management 
activities. 


Resources  include  funds,  staff,  equipment,  and  tools. 

►  Tools  to  support  quantitative  process  management  activities  are  made  available. 
Some  examples  of  quantitative  process  management  tools  include: 

project  management  systems, 
cost  and  schedule  control  systems, 
requirements  management  systems, 
database  systems, 
quantitative  analysis  packages,  and 

deficiency  tracking  packages. _ 
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Level  4:  The  Quantitative  Level 


Ability  2 
Ability  3 


Ability  4 

Activity  1 


Acquisition  organization  management  support  exists  for  collecting, 
recording,  storing,  and  analyzing  process  and  product  measurement  data. 

The  individuals  implementing  or  supporting  quantitative  process 
management  activities  have  experience  or  receive  required  training. 


Experience  means,  for  example,  having  participated  in  a  software  acquisition 
management  role  on  at  least  one  project  and  having  a  minimum  of  three  years 
experience  in  acquisition,  software  measurement,  and  statistical  process  control. 


Some  examples  of  experience  or  training  include: 

defining  and  performing  the  software  acquisition  process; 
modeling  and  analyzing  the  software  acquisition  process; 
selecting,  collecting,  and  verifying  process  measurement 
data; 

applying  basic  quantitative  methods  and  analysis  techniques; 
and 

defining  quantitative  objectives  for  process  management. 


The  members  of  the  project  team  and  groups  supporting  the  software 
acquisition  project  receive  orientation  on  the  objectives  and  values  of 
quantitative  process  management. 

Activities  performed 


The  acquisition  organization’s  software  acquisition  process  capability 
baseline  is  defined  in  quantitative  terms  and  is  maintained  according  to  a 
written  procedure. 

This  procedure  typically  specifies  that: 

1.  Project  teams’  process  performance  is  analyzed  to  establish  the  acquisition  organization’s 
quantitative  process  capability  baseline. 

2.  Process  capability  trends  for  the  acquisition  organization’s  standard  software  acquisition 
process  are  examined  to  predict  likely  deficiencies  or  opportunities  for  improvements. 
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Quantitative  Process  Management 


Activity  2 


Activity  3 


Some  examples  of  using  measured  capability  trends  include: 

predicting  the  occurrence  of  project  deficiencies  and  comparing  the  predictions  to  actuals  and 
predicting  the  distribution  and  severity  of  deficiencies  remaining  in  a  project  team  work  product 
based  on  data  from  reviews . 


3.  Changes  to  the  acquisition  organization’s  standard  software  acquisition  process  are 
tracked  and  analyzed  to  determine  their  effect  on  the  quantitative  process  capability 
baseline. 

Each  project  team’s  quantitative  goals  and  objectives  are  derived  from 
the  acquisition  organization’s  quantitative  process  capability  baseline. 

Refer  to  the  Program  Performance  Management  key  process  area  for  a  description  of 
tailoring  requirements. 

Each  project  team  performs  its  activities  in  accordance  with  its 
documented  quantitative  process  management  plans. 

The  plans  typically  cover: 

1.  The  goals  and  objectives  of  the  project  team’s  quantitative  process  management  activities. 

2.  The  software  acquisition  tasks  or  other  acquisition  tasks  that  will  be  measured  and 
analyzed. 


The  data  collection  and  the  quantitative  analyses  strategy  are  based  on  the  project’s  defined  software 
acquisition  process. _ 

3.  The  instrumentation  of  the  project’s  defined  software  acquisition  process. 


The  instrumentation  is  based  on  the  acquisition  organization’s  measurement  program,  the  description 
of  the  acquisition  organization’s  standard  software  acquisition  process,  and  the  description  of  the 
project's  defined  software  acquisition  process. _ 

4.  The  quantitative  process  management  activities  to  be  performed  and  the  schedule  for 
these  activities. 


In  addition  to  current  organizational  and  project  needs,  measurements  that  may  be  useful  to  future 
efforts  may  be  included. _ 

5.  The  groups  and  individuals  responsible  for  the  quantitative  process  management 
activities. 

6.  The  resources  required  to  perform  the  quantitative  process  management  activities, 
including  staff  and  tools. 

7.  The  procedures  to  be  followed  in  performing  the  quantitative  process  management 
activities. 
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Activity  4 


Activity  5 


The  measurement  data  used  to  quantitatively  control  the  project’s 
defined  software  acquisition  process  are  collected  in  accordance  with  the 
acquisition  organization’s  standard  software  acquisition  process. 


Some  examples  of  measurement  data  include: 

effort,  schedule,  and  cost  estimates  used  in  the  solicitation  phase; 
actual  project  data  on  software  size,  effort,  schedule,  and  cost; 
project  team  productivity  data  (e.g.,  staff  hours  expended,  document  pages 
reviewed,  and  requirements  normally  tested); 

project  team  quality  measurements  (e.g.,  number  and  severity  of  deficiencies 
found  in  the  project  requirements  and  project  team  work  products);  and 
timeliness  of  project  team  work  products. _ 


Project  team  work  products  are  those  products  that  are  produced  by  the  project  team  as  it  executes  the 
project’s  defined  software  acquisition  process  (e.g.,  solicitation,  acquisition  plans,  document  reviews). 
Project  team  work  products  are  not  the  deliverables,  products,  end  items,  or  other  output  produced  by 
the  contractor  in  satisfaction  of  the  contract. 


The  process  typically  specifies  that: 

1 .  The  measurement  data  collected  support  the  acquisition  organization’s  and  the  project 
team’s  measurement  objectives. 

2.  The  specific  measurement  data  to  be  collected,  their  precise  definitions,  the  intended  use 
and  analysis  of  each  measurement,  and  the  process  control  points  at  which  they  are 
collected  are  defined. 

3.  The  measurements  cover  the  properties  of  the  software  acquisition  process  activities  and 
major  software  acquisition  work  products. 

4.  The  verification  of  each  project’s  measurement  data  is  independently  determined. 

5.  The  collected  measurement  data  are  stored  in  the  acquisition  organization’s  software 
acquisition  process  repository  as  appropriate. 

Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 


Each  project’s  defined  software  acquisition  process  is  analyzed  and 
quantitatively  controlled  according  to  the  project’s  quantitative  process 
management  plans. 

The  plans  typically  specify  that: 


1.  Specific  data  analysis  activities  are  predefined. 


I  Some  examples  of  items  analyzed  include: 

input  data  required, 
tools  used, 

data  manipulations  performed, 
information  to  be  derived, 

decision  criteria  used  in  performing  the  analysis,  and 

criteria  for  deciding  what  actions  to  take  as  a  result  of  the  analysis. 
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Activity  6 

Activity  7 
Activity  8 


2.  Measurement  data  on  the  process  activities  throughout  the  project’s  defined  software 
acquisition  process  are  identified,  collected,  and  analyzed. 

3.  The  acceptable  limits  for  each  measurement  are  defined. 


An  example  of  establishing  acceptable  limits  is  to  calculate  the  historical  standard  deviation  from  the 
mean  performance  of  the  process. _ 

4.  The  actual  values  of  each  measurement  are  compared  to  the  acceptable  limits. 

5.  Adjustments  are  made  to  bring  process  performance  in  line  with  the  established 
acceptable  limits. 

6.  Each  project  team’s  software  acquisition  process  performance  is  established  for  the: 

►  Definition  of  the  measurements. 

►  Actual  measurement  data. 

►  Acceptable  limits  for  the  measurements. 

7.  The  process  performance  for  the  software  acquisition  project  team  is  managed  and 
controlled. 

Causal  analysis  is  conducted  on  a  periodic  basis  to  determine  special 
causes  of  variances  from  the  project’s  defined  software  acquisition 
quantitative  process  goals  and  objectives. 

I  An  example  of  a  method  to  determine  root  causes  is  cause/effect  analysis. 

Changes  in  the  project’s  defined  software  acquisition  process  are 
implemented  to  correct  special  causes  of  variance. 

Reports  documenting  the  results  of  the  project  team’s  quantitative 
process  management  activities  are  prepared  and  recorded  in  the  software 
acquisition  organization’s  process  repository. 

Refer  to  the  Process  Definition  and  Maintenance  key  process  area  for  incorporating  process 
data  in  the  repository. 
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Measurement  1 


Measurement  2 


Verification  1 


Verification  2 


Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
quantitative  process  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  quantitative  process 
management  planning  and  the  collection  of  measurement  data, 
and 

completion  of  milestones. _ 


Measurements  are  made  and  used  to  determine  the  effectiveness  of  the 
quantitative  process  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

the  percentage  of  integration  of  the  quantitative  process  management  activities  into 
the  acquisition  organization’s  standard  software  acquisition  process  and  the 
percentage  of  integration  of  the  quantitative  process  management  activities  into  the 
project’s  defined  software  acquisition  process. _ 


Verifying  implementation 


Quantitative  process  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  quantitative  process  management  activities  at 
an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Each  project  team’s  quantitative  process  management  activities  are 
reviewed  by  the  project  manager  on  both  a  periodic  and  event-driven 
basis. 


This  review  may  be  conducted  in  conjunction  with  project  management  oversight 
reviews,  such  as  those  conducted  for  the  Project  Performance  Management  and 
Contract  Performance  Management  key  process  areas. _ 
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Quantitative  Acquisition  Management 

a  key  process  area  for  Level  4:  Quantitative _ 


The  purpose  of  Quantitative  Acquisition  Management  is  to  manage  the  contractual  effort  through 
the  application  of  quantitative  methods. 

Quantitative  Acquisition  Management  involves  utilizing  process  and  product  measurements  as  an 
intrinsic  part  of  management  review  and  oversight  to  quantitatively  manage  the  acquisition  of 
software  products  and  services. 

As  the  acquisition  organization  continues  to  attain  higher  levels  of  maturity  there  is  a  transition 
to  quantitative  methods.  This  transition  is  marked  by  the  involvement  of  all  levels  of  acquisition 
management.  The  result  represents  an  advance  from  contract  performance  management  to 
acquisition  management  using  quantitative  methods.  Another  result  of  this  transition  is  an 
expected  increase  in  the  quality  of  acquired  products  and  services. 

The  quantitative  acquisition  management  process  is  integrated  with  quantitative  process 
management.  The  actions  of  quantitative  process  management  at  the  project  level  and  across  the 
acquisition  organization  are  integral  to  acquisition  management. 

Goals 


Goal  1  Quantitative  objectives  for  the  acquired  products  and  services  are 

defined. 


Goal  2  The  contracted  effort  is  managed  quantitatively. 

Commitment  to  perform 


Commitment  1  The  acquisition  organization  has  a  written  policy  for  quantitatively 
managing  the  acquisition  of  software  products  and  services. 


[The  term  “quantitative  management”  implies  using  quantitative  or  statistical  based 
techniques  for  analyzing  the  acquired  products  and  services,  identifying  causes  of 
performance  variations,  and  making  adjustments  to  bring  the  products  and  services 
within  prescribed  limits. _ 


This  policy  typically  specifies  that: 
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Commitment  2 


Ability  1 


Ability  2 


Activity  1 


1.  Each  project’s  defined  software  acquisition  process  calls  for  planning  and  implementing 
quantitative  control  of  its  software  acquisition. 

2.  Each  project  defines  quantitative  objectives  for  the  acquisition  of  software  products  and 
services  and  collects  measurements  based  on  the  project’s  defined  software  acquisition 
process. 

The  acquisition  organization  has  a  written  policy  that  incorporates 

quantitative  methods  into  management  review  and  oversight  activities. 

Ability  to  perform 


Project  team  personnel  have  experience  and  are  trained  in  quantitative 
methods. 


Experience  means,  for  example,  having  participated  in  an  acquisition  where 
quantitative  methods  have  been  applied  to  the  process,  products,  and  services  of  the 
acquisition. _ 


The  members  of  the  project  team  and  groups  supporting  the  software 
acquisition  project  receive  orientation  on  the  goals  and  values  of 
quantitative  methods. 

Activities  performed 


Each  project  team  performs  its  activities  in  accordance  with  its 
documented  quantitative  acquisition  management  plans. 

These  plans  typically  cover: 

1.  Quantitative  objectives  for  acquired  products  and  services. 

2.  Quantitative  methods  used  to  implement  management  practices. 

3.  Methods  for  the  collection  of  data  for  the  measurement  of  acquired  products  and  services. 

4.  Analysis  of  data  to  determine  deviations  from  stated  objectives. 

5.  The  resources  required  to  perform  collection  and  analysis  of  quantitative  measures. 

6.  The  quality  attributes  expected  in  acquired  products  and  services. 
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Activity  2 


Activity  3 


Activity  4 


Activity  5 


Some  examples  of  software  quality  attributes  are: 

functionality, 
reliability, 
reusability, 
maintainability,  and 

usability. _ 


The  quantitative  objectives  for  each  project’s  software  products  and 
services  are  defined. 

1.  Attributes  are  identified  that  indicate  how  well  the  software  products  will  perform  or  how 
well  they  will  be  engineered  and  maintained. 

2.  Measurable  values  (required  and  desired)  are  defined  for  each  attribute. 

3.  The  methods  to  measure  the  attributes  are  identified. 

The  quantitative  objectives  for  each  project’s  products  and  services  are 
incorporated  into  the  solicitation  package  and  resulting  contract 
according  to  the  project’s  defined  software  acquisition  process. 

The  process  typically  includes  contract  mechanisms  that  provide  the  project  team 
sufficient  data  to  allow  measurement  and  analysis  of  software  products  and  services. 


Each  project’s  evolving  software  products  and  services  are  measured, 
analyzed,  and  compared  to  the  project’s  established  quantitative 
objectives. 


Acquisition  management  uses  the  results  of  these  actions  to  take  corrective  actions  to 
the  project’s  defined  software  acquisition  process  in  order  to  ensure  that  the  project’s 
products  and  services  are  acquired  in  accordance  with  established  objectives. _ 


Refer  to  Activities  2,  3,  and  4  of  the  Quantitative  Process  Management  key  process  area. 

The  project  team  utilizes  quantitative  measurements  as  a  normal  part  of 
management  review  and  oversight  of  acquired  products  and  services. 

Some  of  the  project  management  areas  that  are  tracked  using  quantitative  process  and  product 
measures  are: 

1.  Risk  management. 

2.  Solicitation. 

3.  Evaluation. 

4.  Requirements  development  and  management. 
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Activity  6 


Activity  7 


Measurement  1 


Measurement  2 


Verification  1 


Causal  analysis  is  conducted  on  a  periodic  basis  to  determine  special 
causes  of  variances  from  the  projects’  quantitative  objectives. 

An  example  of  a  method  to  determine  special  causes  is  cause/effect 
analysis. _ 


Changes  are  implemented  to  eliminate  special  causes  of  variance. 

Changes  are  typically  made  to  the  contract  requirements  and  the  project’s  defined  software- 
acquisition  process. 

Refer  to  Activity  5  of  the  Contract  Performance  Management  and  Activities  7and  8  of  the 
Quantitative  Process  Management  key  process  areas. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
quantitative  acquisition  management  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  quantitative  acquisition  management 
planning  and  the  quantitative  objectives  for  the  solicitation  and 
contract,  and 

completion  of  milestones. _ 


Measurements  are  made  and  used  to  determine  the  effectiveness  of  the 
quantitative  acquisition  management  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

analytical  reports  that  address  quality  of  software  products  and 
services, 

percentages  of  variances  from  stated  objectives  (i.e.,  based  on 
upper  and  lower  bounds),  and 

percentages  of  variances  from  quantitative  objectives. _ 


Verifying  implementation 


Quantitative  acquisition  management  activities  are  reviewed  by 
acquisition  organization  management  on  a  periodic  basis. 


L4-12 


CMU/SEI-99-TR-002 


Level  4:  The  Quantitative  Level 


Quantitative  Acquisition  Management 


Verification  2 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  quantitative  acquisition  management  activities 
at  an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 


Quantitative  acquisition  management  activities  are  reviewed  by  the 
project  manager  on  both  a  periodic  and  event-driven  basis. 
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Level  5  -  The  Optimizing  Level 


At  the  Optimizing  Level,  the  acquisition  organization  is  focused  on  continuous  process 
improvement.  An  acquisition  organization  has  the  means  to  identify  processes  that  are 
candidates  for  optimization.  Statistical  evidence  is  available  to  analyze  process  effectiveness  and 
is  used  to  refine  policies.  Technological  innovations  that  exploit  the  best  software  acquisition 
management  and  engineering  practices  are  identified,  appraised,  and  institutionalized. 

Level  5  acquisition  organizations  are  continuously  striving  to  reduce  variation  in  performance 
while  increasing  their  level  of  performance.  Improvement  occurs  both  by  incremental 
advancements  in  the  existing  mechanisms  and  by  innovations  using  new  technologies  and 
techniques. 

Level  5  key  process  areas  are: 

Continuous  Process  Improvement 
Acquisition  Innovation  Management 
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Continuous  Process  Improvement 

a  key  process  area  for  Level  5:  Optimizing 


The  purpose  of  Continuous  Process  Improvement  is  to  evolve  the  software  acquisition  processes 
used  in  the  acquisition  organization  through  managed  continuous  process  improvement. 
Quantitative  objectives  for  the  acquisition  organization’s  standard  software  acquisition  process 
and  the  projects’  defined  software  acquisition  processes  are  the  targets  of  the  improvement 
activity. 

Continuous  Process  Improvement  involves  defining  quantitative  process  improvement  objectives 
with  the  involvement  and  sponsorship  of  acquisition  organization  management.  It  is  a 
continuous  effort  to  proactively  and  systematically  identify,  appraise,  and  implement 
improvements  to  the  acquisition  organization’s  standard  software  acquisition  process  and  the 
projects’  defined  software  acquisition  processes. 

The  commitment  to  continuous  process  improvement  is  acquisition  organization  wide.  Training 
and  incentive  programs  are  established  to  encourage  and  enable  all  acquisition  organization 
personnel  to  participate  in  the  software  acquisition  continuous  process  improvement  activities. 
Improvement  opportunities  are  identified  and  appraised  in  terms  of  how  well  they  move  the 
acquisition  organization  and  its  projects  toward  software  acquisition  continuous  process 
improvement  objectives. 

When  software  acquisition  process  improvements  are  approved  for  normal  practice,  the 
acquisition  organization’s  standard  software  acquisition  process  and  the  projects’  defined 
software  acquisition  processes  are  revised.  The  Process  Definition  and  Maintenance  key  process 
area  defines  the  actions  for  changing  the  acquisition  organization’s  standard  software  acquisition 
process.  The  Project  Performance  Management  key  process  area  defines  the  actions  for  changing 
the  projects’  defined  software  acquisition  processes. 

The  Acquisition  Innovation  Management  key  process  area  defines  the  actions  for  adopting  and 
transforming  new  techniques  and  technologies  into  the  acquisition  organization. 

Goals 


Goal  1  Participation  in  continuous  process  improvement  activities  is  acquisition 

organization  wide. 
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Goal  2 


Commitment  1 


Commitment  2 


The  acquisition  organization’s  standard  software  acquisition  process  and 
the  projects’  defined  software  acquisition  processes  are  improved 
continuously. 


Commitment  to  perform 


The  acquisition  organization  has  a  written  policy  for  the  implementation 
of  software  acquisition  process  improvements. 

This  policy  typically  specifies  that: 

1.  The  acquisition  organization  has  quantitative  objectives  for  improving  the  process 
effectiveness  of  its  standard  software  acquisition  process. 

2.  The  acquisition  organization’s  software  acquisition  process  improvement  activities  are 
directed  toward  improving  the  quality  of  project  team  products  and  services  and 
increasing  project  team  productivity. 

3.  All  of  the  acquisition  organization’s  personnel  are  expected  to  participate  in  improving 
the  software  acquisition  processes. 

Acquisition  organization  management  actively  sponsors  process 
improvement  activities. 

Acquisition  organization  management: 

1.  Establishes  the  organization’s  strategic  objectives  and  plans  for  process  improvement. 

2.  Allocates  resources  for  process  improvement  activities. 

3.  Reviews  and  approves  the  process  improvement  plans  and  objectives. 

4.  Tracks  performance  of  the  continuous  process  improvement  activities  against  their 
defined  objectives. 

5.  Maintains  a  consistent  priority  focus  on  process  improvement  in  the  face  of  project  crises. 

6.  Ensures  that  process  improvement  issues  are  resolved  promptly. 

7.  Rewards  participation  in  the  process  improvement  activities. 
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Ability  1 


Ability  2 


Activity  1 


Ability  to  perform 


Adequate  resources  are  provided  for  continuous  process  improvement 
activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Experienced  individuals  who  have  expertise  in  defining  and  analyzing  software  acquisition  processes  are 
made  available  to  help  the  acquisition  organization  in  its  process  improvement  activities. _ 

Acquisition  organization  personnel  receive  required  training  in 
continuous  process  improvement. 


Some  examples  of  training  for  software  acquisition  management  personnel 
include: 

the  principles  of  process  improvement, 

setting  and  tracking  objectives  for  process  improvement, 

motivation  and  team  building  in  a  continuous  process  improvement  environment, 
managing  technological  and  organizational  change, 
team  building,  and 

teamwork  skills  as  applied  to  continuous  process  improvement. _ 


Some  examples  of  training  for  project  personnel  include: 

the  principles  of  quality  and  process  improvement  and  the  procedures  for 
proposing  process  improvement. _ 


Activities  performed 


The  acquisition  organization  performs  its  activities  in  accordance  with  its 
documented  continuous  process  improvement  plans. 

The  plans  typically: 

1.  Identify  the  resources  required. 

2.  Present  the  quantitative  short-term  and  long-term  objectives  for  software  acquisition 
process  performance  and  improvement. 

3.  Specify  the  procedures  for: 

►  The  acquisition  organization  managers  overseeing  the  process  improvement 
activities. 
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►  The  software  acquisition  managers  planning  and  coordinating  process  improvement 
activities. 

►  Individuals  and  project  teams  identifying,  appraising,  implementing,  and  evaluating 
software  acquisition  process  improvements. 

►  The  teams  developing  process  improvements  for  assigned  software  acquisition 
process  areas. 

4.  Specify  the  administrative  and  support  procedures  required  to  maintain  process 
improvement. 

►  Administrative  procedures  to  encourage  participation  in  and  facilitate  the  process 
improvement  activities  are  included. 

►  Procedures  for  the  oversight  and  review  of  the  process  improvement  activities  by 
administrative  personnel  are  included. 

►  Procedures  for  the  recognition  of  the  roles  and  contribution  of  personnel  to  process 
improvement  are  included. 

5.  Are  reviewed  and  approved  by  acquisition  organization  management. 

6.  Are  managed  and  controlled. 

Activity  2  The  software  acquisition  process  group  coordinates  process  improvement 

activities  throughout  the  acquisition  organization  to  facilitate 
organization-wide  participation. 

The  software  acquisition  process  group: 

1.  Coordinates  the  definition  of  quantitative  objectives  for  software  acquisition  process 
performance  and  improvement  and  reviews  the  objectives  with  acquisition  organization 
management  for  its  endorsement. 

2.  Defines  the  measurement  plans  for  software  acquisition  process  performance. 

3.  Participates  in  the  effort  to  define  the  acquisition  organization’s  training  needs  for  process 
improvement  and  supports  the  development  and  presentation  of  training  course  materials. 

4.  Defines  and  maintains  the  procedures  for  handling  process  improvement  proposals. 

5.  Reviews  process  improvement  proposals  and  coordinates  actions  for  these  proposals. 

6.  Tracks  status,  accomplishments,  and  participation  in  the  process  improvement  activities 
and  periodically  reports  the  results  to  acquisition  organization  management. 
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Activity  3 

Activity  4 
Activity  5 


7.  Reviews,  approves,  manages,  and  controls  any  changes  to  the  acquisition  organization’s 
standard  software  acquisition  process. 

8.  Defines,  establishes,  and  maintains  the  process  improvement  records. 

Refer  to  the  Process  Definition  and  Maintenance  key  process  area  for  an  introduction  to  the 
software  acquisition  process  group  and  the  acquisition  organization ’s  standard  software 
acquisition  process. 

Causal  analysis  is  conducted  on  a  periodic  basis  to  determine  common 
causes  of  variances  from  acquisition  organization’s  standard  software 
acquisition  process. 

Changes  in  the  acquisition  organization’s  standard  software  acquisition 
process  are  implemented  to  correct  common  causes  of  variance. 

Appropriate  process  improvements  are  continuously  transferred  into 
practice  according  to  a  written  procedure. 

This  procedure  typically  specifies  that: 

1.  Process  improvement  proposals  are  submitted. 

The  process  improvement  proposals  may  be  submitted  at  any  time,  by  any  member  of  the  organization, 
and  may  address  any  of  the  software  acquisition  processes  or  the  area  of  process  improvement. _ 

2.  Each  process  improvement  proposal  is  evaluated,  the  expected  benefits  are  determined,  a 
decision  is  made  whether  to  implement  the  proposal,  and  the  decision  rationale  is 
documented. 

3.  Implementation  of  the  approved  process  improvement  actions  is  assigned  and  planned. 

4.  The  status  of  each  process  improvement  proposal  is  tracked. 

5.  Completed  process  improvement  actions  are  reviewed,  verified,  and  approved  before 
closure. 

6.  Submitters  of  process  improvement  proposals  receive: 

►  Prompt  acknowledgment  of  their  proposals. 

►  Notification  of  the  disposition  of  their  proposals. 

7.  Appropriate  process  changes  are  incorporated  into  the  acquisition  organization’s  standard 
software  acquisition  process. 

Refer  to  Activities  2,  3,  and  4  of  the  Process  Definition  and  Maintenance  key  process 
area. 
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8.  Appropriate  changes  are  incorporated  into  the  projects’  defined  software  acquisition 
processes. 

Refer  to  Activity  4  of  the  Project  Performance  Management  key  process  area. 

Activity  6  Records  of  process  improvement  activities  are  maintained  in  the 

acquisition  organization’s  repository  for  software  acquisition  process 
information. 

1.  Information  about  the  initiation,  status,  and  implementation  of  the  process  improvement 
proposals  is  maintained. 

2.  Historical  data  are  maintained  and  reports  produced  on  process  improvement  activities 
and  results. 


Some  examples  of  records  and  reports  include  the: 

projects’  productivity,  quality,  and  schedule  performances; 

projects’  deficiency  histories; 

organizational  quality  and  productivity  trends;  and 

cost,  schedule,  and  productivity  of  software  acquisition  process  definition  and  maintenance. 
Refer  to  Activity  6  of  the  Process  Definition  and  Maintenance  key  process  area. 

Measurement  and  analysis 


Measurement  1  Measurements  are  made  and  used  to  determine  the  status  of  the 

continuous  process  improvement  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

effort  expended; 
funds  expended; 

progress  towards  completion  of  process  improvement  planning,  process 
improvement  records,  and  updates  to  the  software  acquisition  process 
repository;  and 

completion  of  milestones. _ 

Measurement  2  Measurements  are  made  and  used  to  determine  the  effectiveness  of  the 
continuous  process  improvement  activities  and  resultant  products. 

Some  examples  of  measurements  include: 

the  percentage  of  integration  of  process  improvement  activities  into  the 
acquisition  organization’s  standard  software  acquisition  process, 
the  number  of  process  improvement  proposals  submitted  and  implemented  for 
each  process  area, 

the  response  time  for  handling  process  improvement  proposals, 
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Verification  1 


Verification  2 


the  number  and  type  of  recognition  for  process  improvement  activities  awarded, 
and 

analytical  reports  that  address  the  improvement  of  product  and  service  quality. 


Verifying  implementation 


Continuous  process  improvement  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 

The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  continuous  process  improvement  activities  at 
an  appropriate  level  of  abstraction.  The  reviews  verify  that  acquisition  organization 
policy  is  being  implemented.  The  time  between  reviews  should  satisfy  the  needs  of 
the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms  for  exception 
reporting  are  available. _ 


Some  examples  of  review  subjects  include: 

participation  in  the  continuous  process  improvement  activities, 
process  performance, 
needed  changes  in  objectives, 
issues,  and 

revisions  to  the  continuous  process  improvement  plans  as  appropriate. 


Acquisition  organization  managers  and  project  managers  receive 
feedback  on  the  status  and  results  of  continuous  process  improvement 
activities. 

Feedback  is  provided  on  a  periodic  or  event-driven  basis  and  includes: 

1.  A  summary  of  the  major  continuous  process  improvement  activities. 

2.  Significant  innovations  and  actions  taken  to  address  continuous  process  improvement. 

3.  A  summary  status  of  process  improvement  proposals  that  are  submitted,  opened,  and 
completed  or  closed. 

4.  Reports  on  the  effectiveness  of  implemented  process  improvements. 
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Acquisition  Innovation  Management 

a  key  process  area  for  Level  5:  Optimizing 


The  purpose  of  Acquisition  Innovation  Management  is  to  continually  improve  the  acquisition 
process  through  the  adoption  and  transfer  of  new  techniques  and  technologies.  Acquisition 
innovation  management  is  a  primary  responsibility  of  the  acquisition  organization;  however,  the 
adoption  activity  may  be  carried  out  through  individual  acquisition  projects.  While  a  project  can 
act  by  itself,  the  environment  for  adoption  should  be  fostered  and  led  by  the  acquisition 
organization. 

Acquisition  Innovation  Management  involves  the  identification,  appraisal,  implementation, 
adoption,  and  transfer  of  new  techniques  and  technologies  that  support  the  software  acquisition 
process. 

The  focus  is  on  improving  the  acquisition  process  through  the  adoption  and  implementation  of 
new  techniques  and  technologies.  Adoption  of  new  techniques  and  technologies  is  accomplished 
in  concert  with  continuous  process  improvement  (refer  to  the  Continuous  Process  Improvement 
key  process  area). 

Acquisition  innovation  management  of  new  techniques  and  technologies  encompasses  a  range  of 
possibilities.  These  techniques  and  technologies  are  those  which  are  new  on  the  horizon  or  are 
new  to  the  acquisition.  They  may  range  from  introduction  of  a  new  technique  to  the  project 
(such  as  automated  documentation)  to  adoption  of  a  new  management  strategy  (e.g.,  product  line) 
at  the  acquisition  organization  level.  The  acquisition  organization  and  the  project  act  in 
cooperation  to  implement  new  techniques  and  technologies  that  may  provide  a  specific  benefit  to 
the  project,  as  well  as  an  overall  benefit  to  the  organization. 

Goals 


Goal  1  The  acquisition  organization  proactively  adopts  and  implements  new 

techniques  and  technologies  to  improve  the  standard  software  acquisition 
process. 

Goal  2  Participation  in  the  acquisition  innovation  management  process  is 

organization  wide. 
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Commitment  1 


Commitment  2 

Commitment  3 

Ability  1 
AbUity  2 

Ability  3 


Commitment  to  perform 


The  acquisition  organization  has  a  written  policy  for  acquisition 
innovation  management  activities. 

This  policy  typically  specifies  that: 

1.  New  techniques  and  technologies  for  possible  implementation  in  the  acquisition 
organization’s  standard  software  acquisition  process  are  continually  appraised. 

2.  New  techniques  and  technologies  to  determine  their  value,  cost,  risk,  and  benefit  to  the 
acquisition  process  are  appraised. 

3.  Implementation  of  new  techniques  and  technologies  is  managed  and  controlled. 

Acquisition  organization  management  sponsors,  actively  supports,  and 
provides  leadership  for  acquisition  innovation  management. 

Responsibility  for  acquisition  innovation  management  activities  is 
designated. 

Ability  to  perform 


A  group  that  is  responsible  for  performing  and  coordinating  acquisition 
innovation  management  activities  for  the  acquisition  organization  exists. 

Adequate  resources  are  provided  for  acquisition  innovation  management 
activities. 

Resources  include  funding,  staff,  equipment,  and  tools. 

Individuals  performing  acquisition  innovation  management  activities 
have  experience. 


Experience  means,  for  example,  having  had  multiple  acquisition  management  roles 
on  several  projects,  understanding  the  application  of  techniques  and  technologies  in 
the  acquisition  process,  and  understanding  the  objectives  of  the  acquisition 
organization. _ 
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Activity  1 


Activity  2 


Activity  3 


Activities  performed 


The  acquisition  organization  and  each  project  perform  their  activities 
according  to  their  respective  documented  acquisition  innovation 
management  plans. 

The  plans  typically  cover: 

1.  The  appraisal  of  new  techniques  and  technologies  to  determine  their  applicability  and 
appropriateness  for  the  acquisition  organization. 

Some  examples  of  new  techniques  and  technologies  include: 

the  use  of  a  new  documentation  scheme, 

the  employment  of  new  evaluation  methods, 

the  employment  of  new  acquisition  paradigms, 

the  employment  of  asset  management  (reusable  components), 

the  implementation  of  software  architecture  managed  development,  and 

the  use  of  product  line  implementation  and  management. _ 

2.  The  resources  required. 

3.  Assignment  of  responsibilities. 

4.  Review  and  appraisal  of  the  acquisition  innovation  management  activities. 

5.  The  detailing  of  specific  implementation  and  evaluation  practices  and  procedures. 

6.  Preparation  of  process  improvement  proposals. 

Refer  to  Activities  1  and  5  of  the  Continuous  Process  Improvement  key  process  area. 

The  group  responsible  for  conducting  acquisition  innovation 
management  activities  conducts  routine  and  periodic  appraisals  of  new 
techniques  and  technologies  as  candidates  for  inclusion  in  the  acquisition 
organization’s  standard  software  acquisition  process. 

New  approaches  and  technologies  are  appraised  to  determine  their  effect  on  quality 
and  productivity  and  results  are  reported  to  acquisition  organization  management. 

Refer  to  Activities  2  and  5  of  the  Continuous  Process  Improvement  key  process  area. 

The  group  responsible  for  conducting  acquisition  innovation 
management  adapts,  pilots,  and  includes  new  techniques  and  technologies 
beneficial  to  the  acquisition  organization  into  the  standard  software 
acquisition  process. 
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Activity  4 


Activity  5 


Activity  6 


Measurement  1 


Measurement  2 


Piloted  efforts  assigned  to  project  teams  are  performed  in  accordance 
with  its  documented  acquisition  innovation  management  plans. 

The  plans  typically  cover: 

1.  Management  of  the  implementation  process  for  the  inclusion  of  the  new  technique  or 
technology. 

2.  Implementation  process  of  the  adopted  technique  or  technology. 

3.  Evaluation  of  the  effect  of  the  implemented  technique  or  technology. 

4.  Resources  needed  to  manage  the  implementation  of  the  activity. 

The  acquisition  organization,  working  with  the  projects,  implements 
activities  to  foster  an  organization-wide  environment  that  facilitates 
adoption  of  initiatives  beneficial  to  the  acquisition  organization. 

Software  acquisition  management  personnel  are  kept  informed  of  new 
technologies. 

1.  Information  on  new  techniques  and  technologies  is  made  available. 

2.  Information  on  techniques  and  technologies  already  in  use  within  the  acquisition 
organization  is  disseminated. 

3.  Information  on  the  status  of  new  techniques  and  technologies  being  implemented  within 
the  acquisition  organization  is  disseminated. 

Measurement  and  analysis 


Measurements  are  made  and  used  to  determine  the  status  of  the 
acquisition  innovation  management  activities  and  resultant  products. 


Some  examples  of  measurements  include: 

effort  expended, 
funds  expended, 

progress  towards  completion  of  acquisition  innovation  management 
improvement  planning  and  appraisals  of  new  candidate  techniques  and 
technologies,  and 

completion  of  milestones. _ 


Measurements  are  made  and  used  to  determine  the  effectiveness  of  the 
acquisition  innovation  management  activities  and  resultant  products. 
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Acquisition  Innovation  Management 


Verification  1 


Verification  2 


Some  examples  of  measurements  include: 

the  percentage  of  adoption  and  implementation  of  new  techniques  and 
technologies  in  the  project’s  defined  software  acquisition  process;  and 
analytical  reports  that  address  identification,  appraisal,  implementation,  and 
adoption  of  candidate  techniques  and  technologies  for  inclusion  in  the 
acquisition  organization’s  standard  software  acquisition  process. _ 


Verifying  implementation 


Acquisition  innovation  management  activities  are  reviewed  by  acquisition 
organization  management  on  a  periodic  basis. 


The  primary  purpose  of  these  reviews  by  acquisition  organization  management  is  to 
provide  awareness  of,  and  insight  into,  acquisition  innovation  management  activities 
at  an  appropriate  level  of  abstraction.  The  reviews  verily  that  acquisition 
organization  policy  is  being  implemented.  The  time  between  reviews  should  satisfy 
the  needs  of  the  organization  and  may  be  lengthy,  as  long  as  adequate  mechanisms 
for  exception  reporting  are  available. _ 


Acquisition  innovation  management  activities  are  reviewed  by  the  project 
manager  on  both  a  periodic  and  event-driven  basis. 
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The  following  documents  were  consulted  during  the  development  of  the  SA-CMM.  Many  are 
the  result  of  unpublished  research  and  are  not  publicly  available. 

The  Adaptation  of  the  SEI’s  Capability  Maturity  Model  to  the  Air  Force  Software  Acquisition 
Management  Process.  Air  Force  Institute  of  Technology  (Masters  Thesis),  December  1992. 

Buley,  Dr.  Ernest  R.  The  Acquisition  Capability  Assessment  (MTR  92W0000197V1).  McLean, 
Va.:  The  MITRE  Corporation,  October  1992. 

Clapp,  Judith  and  Clark,  Eileen.  A  Study  of  the  Feasibility  of  Using  a  Software  Acquisition 
Maturity  Model  in  the  Department  of  Defense:  The  MITRE  Corporation,  September  1992. 

Creps,  Richard  E.,  et  al.  The  Stars  Conceptual  Framework  for  Reuse  Processes:  November  1992. 

Ferguson,  Jack  R.  and  DeRiso,  Michael  E.  Software  Acquisition:  A  Comparison  ofDoD  and 
Commercial  Practices  (CMU/SEI-94-SR-9).  Pittsburgh,  Pa.:  Software  Engineering  Institute, 
Carnegie  Mellon  University,  October  1994. 

Marciniak,  John  and  Reifer,  Donald.  Software  Acquisition  Management:  New  York:  John  Wiley 
&  Sons,  1989. 

Paulk,  Mark  C.,  et  al.  Capability  Maturity  Model  for  Software,  Version  1.1  (CMU/SEI-94-TR-24 
ADA263403).  Pittsburgh,  Pa.:  Software  Engineering  Institute,  Carnegie  Mellon  University, 

1994. 

Saunders,  Thomas  F.,  et  al.  A  New  Process  for  Acquiring  Software  Architecture  (MTR 
92B0000126).  Bedford,  Ma.:  The  MITRE  Corporation,  November  1992. 

Sherer,  S.  Wayne  and  Cooper,  Jack.  The  Five  Levels  of  Software  Acquisition  Maturity.  Picatinny 
Arsenal,  N.J.:  U.S.  Army,  Armament  Research,  Development,  and  Engineering  Center, 
September  1994. 

Software  Engineering  Institute.  Software  Acquisition  Maturity  Model  Feasibility  Study, 

Comment  Resolutions:  April  1994. 

U.S.  Army  Life  Cycle  Software  Engineering  Centers.  Software  Process  Assessments,  Finding 
Reports:  1992. 

U.S.  General  Accounting  Office.  Information  Technology :  An  Audit  Guide  for  Assessing 
Acquisition  Risks  (GAO/IMTEC  8.1.4),  December  1992. 
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U.S.  General  Accounting  Office.  Information  Technology:  A  Model  to  Help  Managers  Decrease 
Acquisition  Risks  (GAO/1MTEC  8.1.6),  August  1990. 

U.S.  Navy,  Naval  Air  Systems  Command.  Software  Acquisition  Management  Maturity  Model, 
Draft,  September  1992. 

Zanfagna,  Thomas  J.,  et  al.  System  Acquisition  Capability  Maturity  Model,  User’s  Manual  (MTR 
92W0000154).  McLean,  Va.:  The  MITRE  Corporation,  July  1992. 
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acceptance  criteria  -  The  criteria  that  a  system  entity  or  component  must  satisfy  in  order 
to  be  accepted  by  the  buyer,  or  other  authorized  representative. 

acceptance  testing  -  Formal  testing  conducted  to  determine  whether  or  not  a  system 
satisfies  its  acceptance  criteria  and  to  enable  the  customer  to  determine  whether  or  not  to 
accept  the  system  [IEEE-STD-610]. 

acquisition  -  The  process  of  obtaining  through  contract. 

acquisition  organization  -  That  entity  which  has  the  oversight  responsibility  for  the 
software  acquisition  project  and  which  may  have  purview  over  the  acquisition  activities 
of  a  number  of  projects  or  contract  actions. 

acquisition  organization’s  standard  software  acquisition  process  -  (See  software 
acquisition  process.) 

activity  -  Any  step  taken  or  function  performed,  either  mental  or  physical,  toward 
achieving  some  objective.  Activities  include  all  the  work  the  managers  and  technical 
staff  do  to  perform  the  tasks  of  the  project  and  organization. 

application  domain  -  A  bounded  set  of  related  systems  (i.e.,  systems  that  address  a 
particular  type  of  problem).  Development  and  maintenance  in  an  application  domain 
usually  require  special  skills  and/or  resources.  Examples  include  payroll  and  personnel 
systems,  avionics,  command  and  control  systems,  compilers,  and  expert  systems. 

appraise  -  To  evaluate  the  worth,  significance,  or  status  of. 

attributes  (of  software)  -  Characteristics  of  software  such  as  reliability,  maintainability, 
portability,  and  complexity.  These  characteristics  are  sometimes  referred  to  as  quality 
attributes. 

baseline  -  A  specification  or  product  that  has  been  formally  reviewed  and  agreed  upon, 
that  thereafter  serves  as  the  basis  for  further  development,  and  that  can  be  changed  only 
through  formal  change  control  procedures  [IEEE-STD-610]. 

capability  -  Having  the  needed  attributes  to  perform  or  accomplish. 

capability  maturity  model  -  A  description  of  the  stages  through  which  organizations 
evolve  as  they  define,  implement,  measure,  control,  and  improve  their  processes.  The 
model  provides  a  guide  for  selecting  process  improvement  strategies  by  facilitating  the 
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determination  of  current  process  capabilities  and  the  identification  of  the  issues  most 
critical  to  quality  and  process  improvement. 

causal  analysis  -  The  analysis  of  defects  to  determine  their  cause. 

change  control  -  The  review,  approval/disapproval,  implementation,  tracking,  closure, 
and  status  reporting  of  proposed  changes  to  an  item  (change  management). 

commitment  -  A  pact  that  is  freely  assumed,  visible,  and  expected  to  be  kept  by  all  parties. 

common  features  -  The  subdivision  categories  of  the  SA-CMM  key  process  areas.  The 
common  features  are  attributes  that  indicate  whether  the  implementation  and 
institutionalization  of  a  key  process  area  can  be  effective,  repeatable,  and  lasting.  The 
SA-CMM’s  common  features  are  the  following:  commitment  to  perform,  ability  to 
perform,  activities  performed,  measurement  and  analysis,  and  verifying  implementation. 

configuration  -  In  configuration  management,  the  functional  and  physical  characteristics 
of  hardware  or  software  as  set  forth  in  technical  documentation  or  achieved  in  a  product 
[1EEE-STD-6 1 0] . 

configuration  management  -  A  discipline  applying  technical  and  administrative  direction 
and  surveillance  to  identify  and  document  the  functional  and  physical  characteristics  of  a 
configuration  item,  control  changes  to  those  characteristics,  record  and  report  change 
processing  and  implementation  status,  and  verify  compliance  with  specified  requirements 
[IEEE-STD-6 1 0] . 

consistency  -  The  degree  of  uniformity,  standardization,  and  freedom  from  contradiction 
among  the  documents  or  parts  of  a  system  or  component  [IEEE-STD-6 10]. 

contract  -  A  binding  agreement  between  two  or  more  parties  that  establishes  the 
requirements  for  the  products  and  services  to  be  acquired. 

contract  integrity  -  The  adherence  and  compliance  to  contractual  and  legal  policies, 
regulations,  and  other  guidance. 

contract  terms  and  conditions  -  The  stated  legal,  financial,  and  administrative  aspects  of  a 
contract. 

contractor  -  The  entity  delivering  the  product  or  performing  the  service  being  acquired, 
even  if  that  entity  is  part  of  the  acquiring  organization. 

critical  path  -  A  series  of  dependent  tasks  for  a  project  that  must  be  completed  as  planned 
to  keep  the  entire  project  on  schedule. 

deficiency  -  An  inadequacy  in  the  quality  of  a  process,  product,  or  service. _ 
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defined  level  -  (See  maturity  level.) 

defined  software  acquisition  process  -  (See  software  acquisition  process.) 

deliverable  -  A  product  that  is  required  by  the  contract  to  be  delivered  to  the  acquirer  or  other 
designated  recipient. 

deviation  -  A  noticeable  or  marked  departure  from  the  appropriate  norm,  plan,  standard, 
procedure,  or  variable  being  reviewed. 

effective  -  Adequate  to  accomplish  the  intended  purpose. 

efficient  -  Productive,  without  waste. 

end  user  -  The  individual  or  group  who  will  use  the  system  for  its  intended  operational  use 
when  it  is  deployed  in  its  environment. 

end  user  representatives  -  A  selected  sample  of  end  users  who  represent  the  total  population 
of  end  users. 

evaluation  -  The  process  of  determining  satisfaction  of  requirements.  Evaluations  may 
include  methods  such  as  analyses,  inspections,  reviews,  and  tests.  For  acquisition, 
evaluations  are  conducted  throughout  the  contract  period  of  performance. 

event-driven  review  -  A  review  that  is  performed  based  on  the  occurrence  of  an  event  within 
the  project  (e.g.,  a  formal  review  or  the  completion  of  a  life  cycle  stage).  (See  periodic 
review  for  contrast.) 

findings  -  The  conclusions  of  an  assessment,  evaluation,  audit,  or  review  that  identify  the 
most  important  issues,  problems,  or  opportunities  within  the  area  of  investigation. 

function  -  A  set  of  related  actions,  undertaken  by  individuals  or  tools  to  accomplish  a  set 
purpose  or  end. 

goals  -  The  aggregate  result  achieved  by  the  effective  implementation  of  the  common 
features  of  a  key  process  area.  The  goals  signify  the  scope  and  intent  of  each  key  process 
area. 

group  -  An  assemblage  of  personnel  organized  to  serve  a  specific  purpose  or  accomplish  a 
task.  A  group  may  vary  from  a  single  individual  assigned  part  time,  to  several  part-time 
individuals  assigned  from  other  organizations,  to  several  individuals  dedicated  full-time. 

initial  level  -  (See  maturity  level.) 
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institutionalization  -  The  building  of  infrastructure  and  corporate  culture  that  supports 
methods,  practices,  and  procedures  so  that  they  are  the  ongoing  way  of  doing  business,  even 
after  those  who  originally  defined  them  are  gone. 

instrumentation  -  The  application  of  instruments  (or  metrics)  for  observation,  measurement, 
or  control. 

integrate  -  To  make  into  a  whole  by  bringing  all  parts  together. 

key  process  area  -  A  principle  component  of  a  capability  maturity  model’s  organizational 
structure  that  clusters  related  goals  and  common  features  which  model  a  specific  portion  of 
the  process. 

life  cycle  -  (See  software  life  cycle.) 

managed  and  controlled  -  Implies  that  the  version  of  the  work  product  in  use  at  a  given  time 
(past  or  present)  is  known  (i.e.,  version  control),  and  changes  are  incorporated  in  a  controlled 
manner  (i.e.,  change  control). 

manager  -  A  role  that  encompasses  providing  technical  and  administrative  direction  and 
control  to  individuals  performing  tasks  or  activities  within  the  manager’s  area  of 
responsibility.  The  traditional  functions  of  a  manager  include  planning,  resourcing, 
organizing,  directing,  and  controlling  work  within  an  area  of  responsibility. 

maturity  level  -  A  well-defined  evolutionary  plateau  toward  achieving  a  mature  software 
acquisition  process.  The  five  maturity  levels  in  the  SA-CMM  are  Initial,  Repeatable, 
Defined,  Quantitative,  and  Optimizing. 

measure  -  To  ascertain  the  characteristics  or  features  (extent,  dimension,  quantity,  capacity, 
and  capability)  of  something,  especially  by  comparing  with  a  standard. 

measurement  -  The  dimension,  capacity,  quantity,  or  amount  of  something  (e.g.,  300  source 
lines  of  code  or  seven  document  pages  of  design). 

method  -  A  reasonably  complete  set  of  rules  and  criteria  that  establishes  a  precise  and 
repeatable  way  of  performing  a  task  and  arriving  at  a  desired  result. 

methodology  -  A  collection  of  methods,  procedures,  and  standards  that  defines  an  integrated 
synthesis  of  approaches. 

milestone  -  A  scheduled  event  for  which  some  individual  is  accountable  and  that  is  used  to 
measure  progress. 
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non-developmental  item  (NDI)  -  An  item  that  is  available  for  delivery  prior  to  award  of  the 
contract.  NDI  may  be  referred  to  as  a  reusable  item,  government  furnished  item,  or 
commercially  available  item,  depending  on  its  source. 

non-technical  software  requirements  -  Contractual  agreements,  conditions,  and  terms  that 
affect  the  activities  or  products  of  the  software  acquisition  project. 

offeror  -  A  contractor  who  submits  a  proposal  in  response  to  a  solicitation  package. 

optimizing  level  -  (See  maturity  level.) 

organization  -  The  parent  organization  of  the  acquisition  organization. 

organization ’s  measurement  program  -  The  set  of  related  elements  for  addressing  an 
organization’s  measurement  needs.  It  includes  the  definition  of  organization-wide 
measurements,  methods  and  practices  for  collecting  organizational  measurements  and 
analyzing  data,  and  measurement  goals  for  the  organization. 

orientation  -  An  overview  or  introduction  to  a  topic. 

peer  review  -  A  review  of  products  or  services,  following  defined  procedures,  by  peers  for  the 
purpose  of  identifying  deficiencies  and  improvements. 

periodic  review  -  A  review  that  occurs  at  specified  regular  time  intervals.  (See  event-driven 
review  for  contrast.) 

policy  -  A  guiding  principle,  typically  established  by  senior  management,  that  is  adopted  by 
an  organization  or  project  to  influence  decisions. 

prime  contractor  -  An  individual,  partnership,  corporation,  or  association  that  administers  a 
subcontract  to  design,  develop,  and/or  manufacture  one  or  more  products. 

procedure  -  A  written  description  of  a  course  of  action  to  be  taken  to  perform  a  given  task 
[EEEE-STD-6 10] . 

process  -  A  set  of  activities  performed  for  a  given  purpose  (e.g.,  the  software  acquisition 
process). 

process  capability  -  The  range  of  expected  results  that  can  be  achieved  by  following  a 
process.  (See  process  performance  for  contrast.) 

process  capability  baseline  -  A  documented  characterization  of  the  range  of  expected  results 
that  would  normally  be  achieved  by  following  a  specific  process  under  typical  circumstances. 
A  process  capability  baseline  is  typically  established  at  an  organizational  level.  (See  process 
performance  baseline  for  contrast.) 
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process  measurement  -  The  set  of  definitions,  methods,  and  activities  used  to  take 
measurements  of  a  process  and  its  resulting  products  for  the  purpose  of  characterizing  and 
understanding  the  process. 

process  performance  -  Measurements  of  the  actual  results  achieved  by  following  a  process. 
(See  process  capability  for  contrast.) 

project  -  An  undertaking  that  is  focused  on  acquiring  a  specific  product.  The  product  may 
include  hardware,  software,  and  services.  Typically,  a  project  has  its  own  funding,  cost 
accounting,  and  delivery  schedule. 

project  manager  -  The  role  with  total  business  responsibility  for  an  entire  project;  the 
individual  who  directs,  controls,  administers,  and  regulates  a  project  acquiring  software,  a 
hardware/software  system,  or  services.  The  project  manager  is  the  individual  ultimately 
responsible  to  the  end  user. 

project  office  -  The  aggregate  of  individuals  assigned  the  primary  responsibility  for  software 
acquisition  in  the  contracted  effort.  A  project  office  may  vary  in  size  from  a  single  individual 
assigned  part  time  to  a  large  organization  assigned  full  time. 

project  team  -  All  individuals,  including  matrix  support  and  support  contractors,  that  have  an 
assigned  software  acquisition  responsibility  in  the  acquisition  effort.  A  project  team  may 
vary  in  size  from  a  single  individual  assigned  part  time  to  a  large  organization  assigned  full 
time. 

project’s  defined  software  acquisition  process  -  (See  software  acquisition  process.) 

quality  -  The  degree  to  which  a  process,  product,  or  service  satisfies  a  specific  set  of 
attributes  or  requirements. 

quantitative  control  -  Any  quantitative  or  statistically-based  technique  appropriate  to  analyze 
a  software  acquisition  process,  identify  special  causes  of  variations  in  the  performance  of  the 
software  acquisition  process,  and  bring  the  performance  of  the  software  acquisition  process 
within  well-defined  limits. 

quantitative  level  -  (See  maturity  level.) 

repeatable  level  -  (See  maturity  level.) 

required  training  -  Training  required  by  the  acquisition  organization.  (See  training  for 
contrast.) 

risk  -  The  possibility  of  suffering  loss,  injury,  disadvantage,  or  destruction. 
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risk  management  -  The  process  associated  with  identifying,  evaluating,  mitigating,  and 
controlling  project  risks. 

role  -  A  unit  of  defined  responsibilities  that  may  be  assumed  by  one  or  more  individuals. 

selection  official  -  That  individual  within  the  organization  who  is  authorized  to  select  the 
offeror  (and  commit  the  organization)  for  award  of  a  contract. 

software  acquisition  management  personnel  -  Those  individuals  who  are  trained,  educated,  or 
experienced  in  software  acquisition  management  and  who  are  either  assigned  to  or  support 
the  project  team  in  the  performance  of  software  acquisition  activities. 

software  acquisition  plans  -  The  collection  of  plans,  both  formal  and  informal,  used  to 
express  how  software  acquisition  activities  will  be  performed;  for  example,  the  Software 
Acquisition  Risk  Management  Plan  or  Project  Management  Plan. 

software  acquisition  process  -  A  set  of  activities  that  are  used  to  acquire  software  and  the 
associated  products. 

►  acquisition  organization ’s  standard  software  acquisition  process  -  The  acquisition 
organization’s  fundamental  software  acquisition  process  which  guides  the 
establishment  of  each  project’s  defined  software  acquisition  process. 

►  project’s  defined  software  acquisition  process  -  The  project’s  tailored  version  of  the 
acquisition  organization’s  standard  software  acquisition  process. 

software  acquisition  process  assets  -  A  collection  of  entities,  maintained  by  an  organization, 
for  use  by  projects  in  developing,  tailoring,  maintaining,  and  implementing  their  software 
acquisition  processes. 


Some  examples  of  these  software  acquisition  process 
assets  include: 

the  acquisition  organization’s  standard  software 
acquisition  process, 

descriptions  of  the  software  life  cycles  approved  for 
use, 

the  guidelines  and  criteria  for  tailoring  the  acquisition 
organization’s  standard  software  acquisition  process, 
the  organization’s  software  acquisition  process 
database,  and 

a  library  of  software  acquisition  process-related 
documentation.  _ 


Any  entity  that  the  organization  considers  useful  in  performing  the  activities  of 
process  definition  and  maintenance  could  be  included  as  a  process  asset. 
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software  acquisition  process  group  -  This  group  is  responsible  for  the  definition, 
improvement,  and  maintenance  of  the  acquisition  organization’s  standard  software 
acquisition  process  and  related  process  assets,  including  guidelines  for  all  projects  to  tailor 
the  standard  software  acquisition  process  to  their  specific  situations.  It  coordinates  process 
activities  with  the  software  projects  and  related  elements  of  the  organization. 

software  acquisition  process-related  documentation  -  Documents  and  document  fragments 
that  may  be  of  use  to  future  project  teams  when  tailoring  the  acquisition  organization’s 
standard  software  acquisition  process.  The  examples  may  cover  subjects  such  as  a  project’s 
defined  software  acquisition  process,  standards,  procedures,  software  acquisition  risk 
management  plans,  and  training  materials. 

software  acquisition  process  repository  -  A  collection  of  software  acquisition  process 
information  (e.g.,  estimated  and  actual  data  on  software  project  size,  effort,  and  cost;  and 
project  team  productivity  and  quality  data)  gathered  from  the  software  acquisition  projects 
that  is  maintained  by  the  acquisition  organization  to  support  its  software  acquisition 
definition,  maintenance,  and  improvement  activities. 

software  acquisition  project  -  An  undertaking  that  is  focused  on  acquiring  the  software 
components  and  associated  documentation  of  a  system.  A  software  project  may  be  part  of  a 
project  building  a  hardware/software  system. 

software  acquisition-related  group  -  A  collection  of  individuals  (both  managers  and  technical 
staff)  representing  a  software  discipline  that  supports,  but  is  not  directly  responsible  for, 
software  acquisition.  Examples  of  software  disciplines  include  software  configuration 
management  and  software  quality  assurance. 

software  architecture  -  The  organizational  structure  of  the  software  or  module  [EEEE-STD- 
610], 

software  engineering  group  -  The  collection  of  individuals  (both  managers  and  technical 
staff)  who  have  responsibility  for  software  development  and  maintenance  activities  (i.e., 
requirements  analysis,  design,  code,  and  test)  for  a  project.  Groups  performing  software- 
related  work,  such  as  the  software  quality  assurance  group  and  the  software  configuration 
management  group,  are  not  included  in  the  software  engineering  group. 

software  life  cycle  -  The  period  of  time  that  begins  when  a  software  product  is  conceived  and 
ends  when  the  software  is  no  longer  available  for  use.  The  software  life  cycle  typically 
includes  a  concept  phase,  requirements  phase,  design  phase,  implementation  phase,  test 
phase,  installation  and  checkout  phase,  operation  and  maintenance  phase,  and,  sometimes, 
retirement  phase  [IEEE-STD-610]. 

software-related  contractual  requirements  -  All  technical  and  non-technical  requirements 
related  to  the  software  portion  of  the  acquisition. 
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software  support  -  The  process  of  modifying  a  software  system  or  component  after  delivery 
to  correct  faults,  improve  performance  or  other  attributes,  or  adapt  to  a  changed  environment 
[IEEE-STD-610].  As  used  in  this  model,  software  support  is  synonymous  with  software 
logistics. 

solicitation  package  -  When  seeking  suppliers  for  a  particular  acquisition,  it  is  the 
information  distributed  which  tells  the  interested  bidders  what  the  requirements  are,  how  to 
prepare  their  proposals,  how  proposals  will  be  evaluated,  and  when  to  submit  their  proposals. 
Sometimes  called  request  for  proposals  (RFP). 

staff-  Those  personnel  resources  available  to  the  project  manager  to  assist  in  the  execution  of 
the  project.  Staff  personnel  can  be  persons  assigned  full-time,  from  matrixed  in-house 
support  organizations,  and/or  from  support  contractors. 

standard  -  Mandatory  requirements  employed  and  enforced  to  prescribe  a  disciplined 
uniform  approach  to  software  development  or  acquisition. 

standard  software  acquisition  process  -  (See  software  acquisition  process .) 

statement  of  work  -  A  description  of  all  the  work  required  to  complete  a  project,  which  is 
provided  by  the  customer. 

subcontractor  -  An  individual,  partnership,  corporation,  or  association  that  contracts  with  an 
organization  (i.e.,  the  prime  contractor)  to  design,  develop,  and/or  manufacture  one  or  more 
products. 

system  requirement  -  A  condition  or  capability  that  must  be  met  or  possessed  by  a  system  or 
system  component  to  satisfy  a  condition  or  capability  needed  by  a  user  to  solve  a  problem 
[IEEE-STD-610]. 

system  requirements  allocated  to  software  -  The  subset  of  the  system  requirements  that  are  to 
be  implemented  in  the  software  components  of  the  system. 

tailor  -  To  modify  a  process,  standard,  or  procedure  to  better  match  process  or  product 
requirements. 

technical  software  requirements  -  The  system  requirements  allocated  to  software. 

technology  -  The  application  of  science  and/or  engineering  in  accomplishing  a  particular 
result. 

traceability  -  The  ability  to  trace,  in  both  the  forward  and  backward  directions,  the  lineage  of 
a  requirement  from  its  first  level  inception  and  subsequent  refinement  to  its  implementation 
in  a  software  product  and  the  documentation  associated  with  the  software  product. 
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training  -  Project  team  training.  (See  required  training  for  contrast.) 

training  group  -  The  collection  of  individuals  (both  managers  and  staff)  who  are  responsible 
for  coordinating  and  arranging  the  training  activities  for  an  organization.  This  group  typically 
prepares  and  conducts  most  of  the  training  courses  and  coordinates  use  of  other  training 
vehicles. 

training  program  -  The  set  of  related  elements  that  focuses  on  addressing  an  organization’s 
training  needs.  It  includes  an  organization’s  training  plan,  training  materials,  development  of 
training,  conduct  of  training,  training  facilities,  evaluation  of  training,  and  maintenance  of 
training  records. 

transition  -  The  process  of  transferring  responsibility  for  support  of  the  acquired  software 
products  from  the  contractor  to  the  software  support  organization. 

user  -  (See  end  user.) 

verify  -  To  prove  to  be  true  by  demonstration,  evidence,  or  testimony. 

waiver  -  A  document  stating  a  cancellation  or  reduction  of  a  requirement. 

work  product  -  Any  artifact  that  is  an  output  of  defining,  maintaining,  or  using  a  software 
process.  They  can  include  process  descriptions,  plans,  procedures,  requirements  definition, 
design,  and  software. 

written  procedure  -  (See  procedure.) 
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This  appendix  provides  a  summary  of  each  of  the  SA-CMM’s  key  process  areas.  It  can  be  used 
to  get  a  “quick  look”  at  each  key  process  area  through  its  introduction,  goals,  and  top-level 
activities.  It  does  not  provide  the  institutionalization  features  (i.e.,  commitment  to  perform, 
ability  to  perform,  measurement  and  analysis,  and  verifying  implementation)  or  the  details  within 
the  activities.  It  is  intended  for  informational  purposes,  not  for  determining  compliance  with  the 
requirements  of  the  key  process  areas. 

The  institutionalization  features  must  be  in  place  to  ensure  that  the  key  process  areas  are 
implemented  appropriately  and  effectively,  are  solidly  established,  will  be  maintained  over  time, 
and  can  be  applied  successfully  to  new  projects.  Commitment  to  perform  involves  establishing 
organizational  policies  and  management  sponsorship.  Ability  to  perform  involves  providing 
resources,  organizational  structures,  and  training.  Measurement  and  analysis  includes  examples 
of  measurements  that  could  be  taken  to  determine  the  status  and  effectiveness  of  the  activities 
performed.  Verifying  implementation  encompasses  reviews  by  management. 

To  appropriately  establish  a  key  process  area,  the  full  set  of  common  features  and  the  detailed 
activities  must  be  used. 
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Level  1:  The  Initial  Level 

There  are  no  key  process  areas  at  Level  1 . 
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Level  2:  Software  Acquisition  Planning 

The  purpose  of  Software  Acquisition  Planning  is  to  ensure  that  reasonable  planning  for  the 
software  acquisition  is  conducted  and  that  all  elements  of  the  project  are  included. 

Software  Acquisition  Planning  involves  the  preparation  for  software-related  areas  in  system  level 
planning  such  as  early  budgetary  action,  schedule  determination,  acquisition  strategy,  risk 
identification,  and  software  requirements  definition.  There  are  other  traditional  software 
acquisition  planning  activities  that  must  be  performed  in  the  context  of  the  system  as  a  whole  and 
in  coordination  with  the  project  team  (e.g.,  system  requirements  development,  hardware/software 
partitioning,  system  level  software  requirements  allocation,  and  solicitation  management). 
Software  Acquisition  Planning  also  involves  planning  all  aspects  of  the  software  acquisition 
project.  Software  acquisition  planning  documentation  provides  for  implementation  of  all 
software  acquisition-related  policies. 

Software  acquisition  planning  begins  with  the  earliest  identification  of  a  role  for  software  in  the 
system  to  be  acquired.  The  process  starts  when  reasonable  resources  are  assigned  to  form  a 
project  team  for  the  acquisition,  independent  of  whether  or  not  the  team  is  formally  constituted  as 
an  organizational  entity.  Software  acquisition  planning  provides  for  conducting  and 
documenting  software  acquisition  planning  activities  and  participation  in  system  level  planning 
activities  as  appropriate. 
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The  goals  of  Software  Acquisition  Planning  are: 

1.  Software  acquisition  planning  documents  are  prepared  during  system  acquisition  planning 
and  maintained  throughout  the  acquisition. 

2.  Software  acquisition  planning  addresses  the  project’s  entire  software  acquisition  process  and 
life  cycle  support. 

The  top-level  activities  performed  for  Software  Acquisition  Planning  are: 

1 .  Software  acquisition  planning  personnel  are  involved  in  system  acquisition  planning. 

2.  The  project’s  software  acquisition  planning  is  accomplished  in  conjunction  with  system 
acquisition  planning. 

3.  The  software  acquisition  strategy  for  the  project  is  developed  and  documented. 

4.  Software  acquisition  planning  addresses  the  elements  of  the  software  acquisition  process. 

5.  The  project’s  software  acquisition  planning  is  documented  and  the  planning  documentation  is 
maintained  over  the  life  of  the  project. 

6.  Life  cycle  support  of  the  software  is  included  in  software  acquisition  planning 
documentation. 

7.  Life  cycle  cost  and  schedule  estimates  for  the  software  products  and  services  being  acquired 
are  prepared  and  independently  reviewed. 


CMU/SEI-99-TR-002 


Summary  of  KPAs 


Level  2:  Solicitation 

The  purpose  of  Solicitation  is  to  prepare  a  solicitation  package  that  identifies  the  needs  of  a 
particular  acquisition  and  to  select  a  contractor  who  is  best  capable  of  satisfying  the  requirements 
of  the  contract. 

Solicitation  involves  planning  and  performing  the  activities  necessary  to  issue  the  solicitation 
package,  preparing  for  the  evaluation  of  responses,  conducting  the  evaluation,  conducting 
supporting  negotiations,  and  making  recommendations  for  award  of  the  contract.  Solicitation 
ends  with  contract  award. 
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The  goals  of  Solicitation  are: 

1.  The  selection  official  selects  a  contractor  who  is  qualified  to  satisfy  the  contract’s 
requirements  for  the  project’s  software-related  products  and  services. 

2.  Solicitation  activities  are  compliant  .with  relevant  laws,  regulations,  policies,  and  guidance. 

3.  The  solicitation  package  includes  the  contractual  software  requirements  and  proposal 
evaluation  criteria. 

The  top-level  activities  performed  for  Solicitation  are: 

1.  The  project  team  performs  its  activities  in  accordance  with  its  documented  solicitation  plans. 

2.  Solicitation  activities  are  conducted  in  a  manner  compliant  with  relevant  laws,  policies,  and 
guidance. 

3.  The  software  and  evaluation  requirements  are  incorporated  into  the  solicitation  package  and 
resulting  contract. 

4.  Proposals  are  evaluated  in  accordance  with  documented  solicitation  plans. 

5.  Cost  and  schedule  estimates  for  the  software  products  and  services  being  sought  are  prepared. 

6.  Software  cost  and  schedule  estimates  are  independently  reviewed  for  comprehensiveness  and 
realism. 

7.  The  selection  official  uses  proposal  evaluation  results  to  support  his  decision  to  select  an 
offeror. 

8.  The  project  team  takes  action  to  ensure  the  mutual  understanding  of  software  requirements 
and  plans  with  the  selected  offeror(s)  prior  to  contract  signing. 


C-6 


CMU/SEI-99-TR-002 


Summary  of  KPAs 


Level  2:  Requirements  Development  and  Management 

The  purpose  of  Requirements  Development  and  Management  is  to  establish  a  common  and 
unambiguous  definition  of  software-related  contractual  requirements  that  is  understood  by  the 
project  team,  end  user,  and  the  contractor  team.  Software-related  contractual  requirements 
consist  of  technical  requirements  (system  requirements  allocated  to  software)  and  non-technical 
requirements  (contractual  agreements,  conditions,  and  terms  affecting  the  software  portion  of  the 
acquisition).  This  key  process  area  is  divided  into  two  subprocesses;  development  of  software- 
related  contractual  requirements  and  the  management  of  these  requirements  for  the  duration  of 
the  acquisition. 

Software  requirements  development  involves  those  activities  in  which  system  level  requirements 
are  decomposed  and  allocated  to  software.  To  ensure  software  is  appropriately  addressed  during 
system  requirements  definition  and  solicitation  package  preparation,  the  project  team  participates 
with  the  overall  system  acquisition  team.  Reuse  of  existing  software  assets,  including 
architecture,  is  analyzed  for  use  in  satisfying  requirements.  Requirements  development  often 
involves  direct  participation  from  the  end  user  to  ensure  that  system-level  requirements  are  well 
understood. 

Software  requirements  management  involves  establishing  and  maintaining  agreement  among  the 
project  team,  including  the  end  user,  and  contractor  team  with  respect  to  the  software-related 
contractual  requirements.  It  involves  baselining  the  software  requirements  and  controlling  all 
subsequent  requirements  changes.  The  contract  and  this  key  process  area  address  both  technical 
and  non-technical  software  requirements. 

Requirements  development  and  management  begins  with  the  translation  of  operational  or  end 
user  requirements  into  solicitation  documentation  (e.g.,  specifications)  and  ends  with  the  transfer 
of  responsibility  for  the  support  of  the  software  products. 

Software-related  contractual  requirements  define  the  scope  of  the  software  effort.  Software- 
related  contractual  requirements  are  incorporated  into  software  project  plans,  activities,  and 
products  in  an  orderly  manner.  Requirements  management  ensures  that  software  requirements 
are  unambiguous,  traceable,  verifiable,  documented,  and  controlled. 
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The  goals  of  Requirements  Development  and  Management  are: 

1 .  Software-related  contractual  requirements  are  developed,  managed,  and  maintained. 

2.  The  end  user  and  other  affected  groups  have  input  to  the  software-related  contractual 
requirements  over  the  life  of  the  acquisition. 

3.  Software-related  contractual  requirements  are  traceable  and  verifiable. 

4.  The  software-related  contractual  requirements  baseline  is  established  prior  to  release  of  the 
solicitation  package. 

The  top-level  activities  performed  for  Requirements  Development  and  Management  are: 

1.  The  project  team  performs  its  activities  in  accordance  with  its  documented  requirements 
development  and  management  plans. 

2.  The  project  team  develops,  baselines,  and  maintains  software-related  contractual 
requirements  and  places  them  under  change  control  early  in  the  project,  but  not  later  than 
release  of  the  solicitation  package. 

3.  The  project  team  appraises  system  requirements  change  requests  for  their  impact  on  the 
software  being  acquired. 

4.  The  project  team  appraises  all  changes  to  the  software-related  contractual  requirements  for 
their  impact  on  performance,  architecture,  supportability,  system  resource  utilization,  and 
contract  schedule  and  cost. 

5.  Bi-directional  traceability  between  the  contractual  requirements  and  the  contractor  team’s 
software  work  products  and  services  is  maintained  throughout  the  effort. 

6.  The  end  user  and  other  affected  groups  are  involved  in  the  development  of  all  software- 
related  contractual  requirements  and  any  subsequent  change  activity. 
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Level  2:  Project  Management 

The  purpose  of  Project  Management  is  to  manage  the  activities  of  the  project  office  and 
supporting  organizations  to  ensure  a  timely,  efficient,  and  effective  software  acquisition. 

Project  Management  involves  planning,  organizing,  staffing,  directing,  and  controlling  project 
activities,  such  as  determining  project  tasks,  estimating  software  effort  and  cost,  scheduling 
activities  and  tasks,  training,  leading  the  assigned  personnel,  and  accepting  software  products  and 
services. 

Project  management  begins  when  the  project  office  is  officially  chartered  and  terminates  when 
the  acquisition  is  completed. 
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The  goals  of  Project  Management  are: 

1.  Project  management  activities  are  planned,  organized,  controlled,  and  communicated. 

2.  The  performance,  cost,  and  schedule  objectives  of  the  software  acquisition  project  are 
measured  and  controlled  throughout  the  software  acquisition. 

3.  Problems  discovered  during  the  software  acquisition  are  managed  and  controlled. 

The  top-level  activities  to  be  performed  for  Project  Management  are: 

1.  The  project  team  performs  its  activities  in  accordance  with  its  documented  software 
acquisition  management  plans. 

2.  The  roles,  responsibilities,  and  authority  for  the  project  functions  are  documented, 
maintained,  and  communicated  to  affected  groups. 

3.  The  project  team’s  commitments,  and  changes  to  commitments,  are  communicated  to 
affected  groups. 

4.  The  project  team  tracks  the  risks  associated  with  cost,  schedule,  resources,  and  the  technical 
aspects  of  the  project. 

5.  The  project  team  tracks  project  issues,  status,  execution,  funding,  and  expenditures  against 
project  plans  and  takes  action. 

6.  The  project  team  implements  a  corrective  action  system  for  the  identification,  recording, 
tracking,  and  correction  of  problems  discovered  during  the  software  acquisition. 

7.  The  project  team  keeps  its  plans  current  during  the  life  of  the  project  as  replanning 
occurs,  issues  are  resolved,  requirements  are  changed,  and  new  risks  are  discovered. 
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Level  2:  Contract  Tracking  and  Oversight 

The  purpose  of  Contract  Tracking  and  Oversight  is  to  ensure  that  the  software  activities  under 
contract  are  being  performed  in  accordance  with  contractual  requirements. 

Contract  Tracking  and  Oversight  involves  providing  ongoing  inputs  and  guidance  to  the 
contractor’s  effort  and  identifying  risks  and  problems  in  the  effort. 

Contract  tracking  and  oversight  begins  with  the  award  of  the  contract  and  ends  at  the  conclusion 
of  the  contract’s  period  of  performance. 

The  contract  provides  the  binding  agreement  for  establishing  the  requirements  for  the  software 
products  and  services  to  be  acquired.  It  establishes  the  mechanism  to  allow  the  project  team  to 
oversee  the  contractor  team’s  software  activities  and  evolving  products  and  to  evaluate  any 
software  products  and  services  being  acquired.  It  also  provides  the  vehicle  for  mutual 
understanding  between  the  project  team  and  the  contractor  of  the  software  requirements  of  the 
contract. 
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The  goals  of  Contract  Tracking  and  Oversight  are: 

1.  The  project  team  has  sufficient  insight  into  the  contractor’s  software  engineering  effort  to 
ensure  the  effort  is  managed  and  controlled  and  complies  with  contract  requirements. 

2.  The  project  team  and  contractor  team  maintain  ongoing  communication  and  commitments 
are  agreed  to  by  both  parties. 

3.  The  contract,  and  any  changes,  adhere  to  relevant  laws,  policies,  regulations,  and  other 
planned  guidance  and  implements  project  software  acquisition  requirements. 

The  top-level  activities  performed  for  Contract  Tracking  and  Oversight  are: 

1.  The  project  team  performs  its  activities  in  accordance  with  its  documented  contract  tracking 
and  oversight  plans. 

2.  The  project  team  reviews  required  contractor  software  planning  documents  which,  when 
satisfactory,  are  used  to  oversee  the  contractor  team’s  software  engineering  effort. 

3.  The  project  team  conducts  periodic  reviews  and  interchanges  with  the  contractor  team. 

4.  The  actual  cost  and  schedule  of  the  contractor’s  software  engineering  effort  are  compared  to 
planned  schedules  and  budgets  and  issues  are  identified. 

5.  The  size,  critical  computer  resources,  and  technical  activities  associated  with  the 
contractor  team’s  work  products  are  tracked  and  issues  identified. 

6.  The  project  team  reviews  and  tracks  the  development  of  the  software  engineering 
environment  required  to  provide  life  cycle  support  for  the  acquired  software  and  issues 
are  identified. 

7.  Any  issues  found  by  the  project  team  during  contract  tracking  and  oversight  are 
recorded  in  the  appropriate  corrective  action  system,  action  taken,  and  tracked  to  closure. 

8.  The  project  team  ensures  that  changes  to  the  software-related  contractual  requirements  are 
coordinated  with  all  affected  groups  and  individuals,  such  as  the  contracting  official, 
contractor,  and  end  user. 
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Level  2:  Evaluation 


The  purpose  of  Evaluation  is  to  provide  objective  evidence  that  the  evolving  software  products 
and  services  satisfy  contract  requirements  prior  to  acceptance  and  transition  to  support. 

Evaluation  involves  the  development  of  requirements  for  the  evaluation  approach,  including 
acceptance  criteria,  which  are  incorporated  into  both  the  solicitation  package  and  the  contract. 
Evaluations  are  conducted  throughout  the  contract  performance  period  and  results  are  analyzed  to 
determine  acceptability  of  the  software  products  and  services.  Evaluation  activities  are  designed 
to  reduce  interference  with  contractor-performed  evaluations  and  to  reduce  duplication  of 
evaluation  efforts.  Evaluation  supports  the  activities  that  establish  and  verify  the  contractual 
requirements.  Evaluation  interacts  with  the  Solicitation,  Requirements  Development  and 
Management,  and  Contract  Tracking  and  Oversight  key  process  areas. 

Evaluation  begins  with  development  of  the  system  requirements  and  ends  when  the  software 
acquisition  is  completed. 
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The  goals  of  Evaluation  are: 

1 .  Evaluation  requirements  are  developed  in  conjunction  with  the  technical  requirements  and 
are  maintained  over  the  life  of  the  acquisition. 

2.  Evaluations  are  planned  and  conducted  throughout  the  total  period  of  the  acquisition  to 
provide  an  integrated  approach  that  satisfies  evaluation  requirements  and  takes  advantage  of 
all  evaluation  results. 

3.  Evaluations  provide  an  objective  basis  to  support  the  decision  for  acceptance  of  the  software 
products  and  services. 

The  top-level  activities  performed  for  Evaluation  are: 

1.  The  project  team  performs  its  activities  in  accordance  with  its  documented  evaluation  plans. 

2.  The  project’s  evaluation  requirements  are  developed  in  conjunction  with  the  development  of 
the  system  or  software  technical  requirements. 

3.  The  project’s  evaluation  activities  are  planned  to  minimize  duplication  and  take  advantage  of 
all  evaluation  results,  where  appropriate. 

4.  The  project  team  appraises  the  contractor  team’s  performance  over  the  total  period  of  the 
contract  for  compliance  with  requirements. 

5.  Planned  evaluations  are  performed  on  the  evolving  software  products  and  services  prior  to 
acceptance  for  operational  use. 

6.  Results  of  the  evaluations  are  analyzed  and  compared  to  the  contract’s  requirements  to 
establish  an  objective  basis  to  support  the  decision  to  accept  the  products  and  services  or  to 
take  further  action. 
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Level  2:  Transition  to  Support 

The  purpose  of  Transition  to  Support  is  to  provide  for  the  transition  of  the  software  products 
being  acquired  to  the  eventual  software  support  organization.  The  necessary  resources  are 
identified,  budgeted  for,  and  are  available  when  needed.  The  designated  software  support 
organization  is  fully  prepared  to  accept  responsibility  for  the  software  products  in  time  to  ensure 
uninterrupted  support. 

Transition  to  Support  involves  developing  and  implementing  the  plans  for  transitioning  the 
acquired  software  products.  It  also  involves  ensuring  that  the  contractor  team  and  the  software 
support  organization  are  informed  on  the  contents  of  the  software  engineering  and  support 
environments.  The  project  team  provides  for  an  orderly,  smooth  transition  of  the  software 
products  from  the  contractor  team  to  the  software  support  organization. 

Transition  to  support  begins  with  the  earliest  definition  of  software  requirements  and  ends  when 
the  responsibility  for  the  software  products  is  turned  over  to  the  software  support  organization. 
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The  goals  of  Transition  to  Support  are: 

1 .  The  project  team  ensures  the  software  support  organization  has  the  capacity  and  capability  to 
provide  the  required  support  upon  assumption  of  responsibility  for  the  support  of  the 
software  products. 

2.  There  is  no  loss  in  continuity  of  support  to  the  software  products  during  transition  from  the 
contractor  to  the  software  support  organization. 

3.  Configuration  management  of  the  software  products  is  maintained  throughout  the  transition. 

The  top-level  activities  performed  for  Transition  to  Support  are: 

1.  The  project  team  performs  its  activities  in  accordance  with  its  documented  transition  to 
support  plans. 

2.  Responsibility  for  the  software  products  is  transferred  only  after  the  software  support 
organization  demonstrates  its  capability  and  capacity  to  modify  and  support  the  software 
products. 

3.  The  project  team  conducts  activities  to  ensure  that  support  of  the  software  products  is 
maintained  and  is  effective  during  the  transition  from  the  contractor  to  the  software  support 
organization. 

4.  The  project  team  oversees  the  configuration  control  of  the  software  products  throughout  the 
transition. 
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Level  3:  Process  Definition  and  Maintenance 

The  purpose  of  Process  Definition  and  Maintenance  is  to  establish  the  acquisition  organization’s 
standard  software  acquisition  process  and  an  organizational  responsibility  for  stabilizing  and 
maintaining  the  standard  software  acquisition  process. 

Process  Definition  and  Maintenance  involves  understanding  the  organization’s  and  projects’ 
software  acquisition  processes,  collecting  a  set  of  software  acquisition  process  assets,  and 
coordinating  efforts  to  appraise  and  improve  software  acquisition  processes. 

The  acquisition  organization  provides  the  long-term  commitments  and  resources  to  establish  and 
maintain  a  software  acquisition  process  group.  This  group  is  responsible  for  the  definition, 
maintenance,  and  improvement  of  the  acquisition  organization’s  standard  software  acquisition 
process  and  other  process  assets,  including  guidelines  for  all  projects  to  tailor  the  standard 
software  acquisition  process  to  their  specific  situations.  It  coordinates  process  activities  with  the 
software  projects  and  related  elements  of  the  organization. 
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The  goals  of  Process  Definition  and  Maintenance  are: 

1.  A  standard  software  acquisition  process  for  the  acquisition  organization  is  defined,  managed, 
and  controlled. 

2.  Process  definition  and  maintenance  activities  are  coordinated  across  the  acquisition 
organization. 

3.  Information  relating  to  the  use  of  the  acquisition  organization’s  standard  software  acquisition 
process  by  the  software  acquisition  projects  is  collected,  analyzed,  and  made  accessible. 

The  top-level  activities  performed  for  Process  Definition  and  Maintenance  are: 

1.  The  acquisition  organization  performs  its  activities  in  accordance  with  its  documented 
process  definition  and  maintenance  plans. 

2.  The  acquisition  organization’s  standard  software  acquisition  process  is  defined  and 
maintained  in  accordance  with  its  documented  process  definition  and  maintenance  plans. 

3.  The  acquisition  organization’s  standard  software  acquisition  process  is  appraised  periodically 
and  action  plans  developed  and  implemented  to  address  the  findings  of  the  appraisal. 

4.  The  acquisition  organization’s  and  projects’  activities  for  defining  and  maintaining  their 
software  acquisition  processes  are  coordinated  at  the  organization  level. 

5.  Guidelines  and  criteria  for  a  project’s  selection  and  tailoring  of  the  acquisition  organization’s 
standard  software  acquisition  process  are  developed  and  maintained. 

6.  An  organizational  repository  of  software  acquisition  process  information  is  established, 
managed,  controlled,  and  maintained  to  support  process  definition  and  maintenance 
activities. 

7.  Project  teams  are  informed  of  the  acquisition  organization’s  activities  for  process  definition 
and  maintenance  and  of  the  projects’  tailoring  of  the  acquisition  organization’s  standard 
software  acquisition  process. 
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Level  3:  Project  Performance  Management 

The  purpose  of  Project  Performance  Management  is  to  manage  the  software  acquisition  project 
according  to  a  defined  software  acquisition  process. 

Project  Performance  Management  involves  developing  the  project’s  defined  software  acquisition 
process  and  managing  the  acquisition  using  this  defined  process.  The  project’s  defined  software 
acquisition  process  is  tailored  from  the  acquisition  organization’s  standard  software  acquisition 
process  to  address  specific  attributes  of  the  project. 

The  project’s  management  plans  are  based  on  the  project’s  defined  software  acquisition  process. 
These  plans  describe  how  the  project’s  defined  software  acquisition  process  will  be  implemented 
and  managed. 

The  basic  requirements  for  estimating,  planning,  and  tracking  a  software  acquisition  project  are 
established  in  the  Software  Acquisition  Planning,  Project  Management,  and  Contract  Tracking 
and  Oversight  key  process  areas.  The  emphasis  in  Project  Performance  Management  at  Level  3 
shifts  from  reacting  to  acquisition  problems  and  issues  to  anticipating  these  problems  and  acting 
to  mitigate  the  risk. 
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The  goals  of  Project  Performance  Management  are: 

1 .  The  project  is  managed  according  to  a  defined  software  acquisition  process  which  is  tailored 
from  the  acquisition  organization’s  standard  software  acquisition  process. 

2.  The  project  team  achieves  it  software  acquisition  objectives. 

The  top-level  activities  performed  for  Project  Performance  Management  are: 

1.  The  project’s  defined  software  acquisition  process  is  developed  and  documented  by  tailoring 
the  acquisition  organization’s  standard  software  acquisition  process  according  to  the 
organization’s  tailoring  guidelines. 

2.  The  project  team  develops  and  maintains  the  Project  Management  Plan  in  accordance  with 
the  acquisition  organization’s  standard  software  acquisition  process. 

3.  The  project  team’s  software  acquisition  management  activities  are  performed  in  accordance 
with  the  project’s  defined  software  acquisition  process  and  the  Project  Management  Plan. 

4.  The  project’s  defined  software  acquisition  process  is  revised  as  required  to  remain  consistent 
with  current  project  objectives. 

5.  The  project  team  coordinates  its  activities  with  other  organizations  and  activities  supporting 
the  project. 

6.  The  acquisition  organization’s  software  acquisition  process  repository  is  used  for  project 
planning,  estimating,  and  management. 

7.  Critical  dependencies  are  identified,  negotiated,  and  managed. 

8.  The  project  team  performs  periodic  reviews  to  ensure  current  and  projected  needs  of  the  end 
user  will  be  satisfied. 

9.  Measurements  are  used  to  determine  project  team  performance  and  trends  analyzed. 

10.  The  project  team  identifies  and  analyzes  risks  and  identifies  specific  risk  mitigation  actions 
for  those  risks. 

11.  The  project  team’s  software  acquisition  lessons  learned  are  identified,  documented,  and 
entered  into  the  acquisition  organization’s  software  acquisition  process  repository. 
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Level  3:  Contract  Performance  Management 

The  purpose  of  Contract  Performance  Management  is  to  implement  a  defined  contract 
management  process,  the  objective  of  which  is  to  acquire  software  products  and  services  that 
satisfy  contract  requirements. 

Contract  Performance  Management  involves  appraising  the  contractor  team’s  software 
engineering  performance  and  the  quality  of  the  evolving  products  and  ongoing  services.  Based 
on  the  results  of  the  appraisals,  the  acquisition  may  be  adjusted.  The  process  includes  evaluation 
of  final  products  and  services  to  determine  satisfaction  of  contractual  requirements.  The 
emphasis  in  contract  performance  management  is  to  be  proactive  regarding  contractor  team 
performance  and  contract  compliance  issues  and  to  minimize  the  effects  of  these  issues. 
Additional  activities  include  contributing  to  the  project’s  risk  management  activities,  fostering  an 
environment  of  mutual  cooperation  with  the  contractor,  and  identifying  improvements  to  the 
contract  performance  management  process. 

The  contract  performance  management  process  integrates  contract  performance  management 
activities  with  other  project  management  activities.  Contract  Performance  Management  builds 
on  the  Contract  Tracking  and  Oversight  and  Evaluation  key  process  areas.  Contract  performance 
management  begins  when  the  contract  is  awarded  and  ends  at  the  conclusion  of  the  contract’s 
period  of  performance. 
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The  goals  of  Contract  Performance  Management  are: 

1.  The  quality  of  contractor  team  process,  performance,  products,  and  services  is  appraised 
throughout  the  contract’s  period  of  performance  to  identify  risks  and  take  action  to  mitigate 
those  risks  as  early  as  possible. 

2.  Contract  Performance  Management  activities  intended  to  foster  a  cooperative  and  productive 
environment  among  the  end  user,  project  team,  and  the  contractor  team  are  implemented. 

The  top-level  activities  performed  for  Contract  Performance  Management  are: 

1.  The  project  team  performs  its  activities  in  accordance  with  its  documented  contract 
performance  management  plans. 

2.  The  contractor  team’s  software  engineering  process  is  appraised  according  to  the  project’s 
defined  software  acquisition  process. 

3.  Results  of  the  contractor  team’s  engineering  activities  are  appraised  according  to  the  project’s 
defined  software  acquisition  process. 

4.  Measurements  from  appraisals  are  used  to  evaluate  the  contractor  team’s  performance  and 
trends  analyzed. 

5.  As  understanding  of  the  contractor  team’s  software  engineering  process,  products,  and 
services  improves,  the  project  team  may  propose  changes  to  the  software  acquisition 
approach  to  mitigate  risks. 

6.  The  end  user  periodically  participates  in  the  evaluation  of  evolving  software  products  and 
services  to  determine  the  satisfaction  of  operational  requirements. 

7.  Contract  performance  management  activities  are  performed  to  foster  a  cooperative  and 
productive  environment  among  the  end  user,  project  team,  and  the  contractor  team. 
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Level  3:  Acquisition  Risk  Management 

The  purpose  of  Acquisition  Risk  Management  is  to  identify  risks  as  early  as  possible,  adjust  the 
acquisition  strategy  to  manage  those  risks,  and  develop  and  implement  a  risk  management 
process  as  an  integral  part  of  the  acquisition  organization’s  standard  software  acquisition  process. 
Acquisition  risk  management  begins  with  the  process  of  defining  the  system  need  and  terminates 
when  the  software  acquisition  is  completed.  Acquisition  risk  management  becomes  an  integral 
part  of  the  solicitation,  project  performance  management,  and  contract  performance  management 
processes. 

Acquisition  risk  management  is  a  two-part  process.  First,  the  software  acquisition  strategy 
identifies  the  risks  associated  with  the  acquisition  of  the  system  and  the  approach  is  planned 
based  on  those  risks.  Second,  a  process  is  employed  to  manage  the  risks  throughout  the 
acquisition. 

Risk  identification  includes  categorization  of  the  risk  based  on  historical  data  and  estimates  to 
determine  the  impact  of  each  risk  on  quality,  performance,  schedule,  and  cost.  The  risks  are 
analyzed  to  determine  their  impact  on  acquisition  strategy  and  software  engineering.  Analysis 
includes  determining  the  driver  of  each  risk  area  and  the  impact  of  the  risk  so  that  risk  handling 
strategies  may  be  proposed  and  tested. 

Acquisition  risk  management  is  planned  through  the  Software  Acquisition  Risk  Management 
Plan  which  details  the  processes  to  take  place  in  acquisition  planning  and  software  acquisition 
management.  The  Software  Acquisition  Risk  Management  Plan  describes  the  management 
actions  and  procedures  to  identify,  analyze,  and  rank  order  risks,  and  the  risk  handling  methods 
to  be  applied. 
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The  goals  of  Acquisition  Risk  Management  are: 

1.  Project- wide  participation  in  the  identification  and  mitigation  of  risks  is  encouraged  and 
rewarded. 

2.  The  project  team’s  defined  software  acquisition  process  provides  for  the  identification, 
analysis,  and  mitigation  of  risks  for  all  project  functions. 

3.  Project  reviews  include  the  status  of  identified  risks. 

The  top-level  activities  performed  for  Acquisition  Risk  Management  are: 

1.  Software  acquisition  risk  management  activities  are  integrated  into  software  acquisition 
planning. 

2.  The  Software  Acquisition  Risk  Management  Plan  is  developed  in  accordance  with  the 
project’s  defined  software  acquisition  process. 

3.  The  project  team  performs  its  software  acquisition  risk  management  activities  in  accordance 
with  its  documented  plans. 

4.  The  project  team  encourages  and  rewards  project-wide  participation  in  the  identification  and 
mitigation  of  risks. 

5.  Risk  management  is  conducted  as  an  integral  part  of  the  solicitation,  project  performance 
management,  and  contract  performance  management  processes. 

6.  Software  acquisition  risks  are  analyzed,  tracked,  and  controlled  until  mitigated. 

7.  Project  reviews  include  the  status  of  identified  risks. 
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Level  3:  Training  Program 

The  purpose  of  Training  Program  is  to  develop  the  skills  and  knowledge  of  individuals  so  they 
can  perform  their  software  acquisition  roles  effectively  and  efficiently. 

Training  Program  involves  appraisal  of  training  requirements  at  the  acquisition  organization, 
project,  and  individual  levels.  The  acquisition  organization  surveys  its  current  and  future  skill 
needs  and  determines  how  these  skills  will  be  obtained.  Current  weaknesses  of  the  acquisition 
organization  are  understood  and  plans  are  developed  to  systematically  address  the  weaknesses. 

Some  skills  are  effectively  and  efficiently  imparted  through  informal  vehicles,  whereas  other 
skills  need  more  formal  training  vehicles  to  be  effectively  and  efficiently  imparted.  The 
appropriate  vehicles  are  selected  and  used. 

Members  of  the  acquisition  organization  are  schooled  in  the  standard  software  acquisition 
process,  the  project,  the  domain,  and  in  the  skills  and  knowledge  needed  to  perform  their  jobs 
effectively.  Members  effectively  use,  or  are  prepared  to  use,  the  capabilities  and  features  of  the 
existing  and  planned  work  environment.  The  project  teams  become  more  effective  through  a 
better  understanding  of  their  work  processes. 

This  key  process  area  covers  the  group  that  is  performing  the  organization’s  training  function. 
The  processes  identifying  specific  training  topics  (e.g.,  knowledge  or  skills  needed)  are  contained 
in  the  common  feature  “Ability  to  perform”  of  the  individual  key  process  areas. 
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The  goals  of  Training  Program  are: 

1.  Training  required  for  the  projects’  to  achieve  their  software  acquisition  objectives  is 
identified  and  provided. 

2.  The  training  program  satisfies  the  acquisition  organization’s  training  needs,  including 
training  on  the  standard  software  acquisition  process. 

The  top-level  activities  performed  for  Training  Program  are: 

1 .  The  organization’s  training  program  is  planned,  developed,  implemented,  and  maintained  to 
support  the  organization’s  training  requirements. 

2.  Each  software  acquisition  project  identifies  specific  training  needs  and  develops  a  training 
plan  in  accordance  with  training  program  procedures. 

3.  Software  acquisition  training  for  the  organization  is  provided  in  accordance  with  the 
organization’s  training  program. 

4.  A  waiver  procedure  for  required  training  is  established  and  used  to  determine  whether 
individuals  already  possess  the  knowledge  and  skills  required  to  perform  their  designated 
roles. 

5.  Training  records  are  maintained. 

6.  Measurements  are  used  to  determine  the  quality  of  the  training  program. 
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Level  4:  Quantitative  Process  Management 

The  purpose  of  Quantitative  Process  Management  is  to  quantitatively  control  the  project’s 
performance  resulting  from  implementation  of  the  software  acquisition  process.  Projects  fully 
implementing  quantitative  process  management  will  have  stable  processes  that  are  under 
quantitative  control.  Additionally,  the  capability  of  the  acquisition  organization’s  standard 
software  acquisition  process  is  defined  quantitatively. 

Quantitative  Process  Management  involves  each  project  team  setting  performance  objectives, 
measuring  performance,  analyzing  results,  and  making  adjustments  to  maintain  performance 
within  acceptable  limits.  Performance  variations  (i.e.,  variations  attributable  to  specific 
implementations  of  the  process)  are  measured  and  actions  taken  to  bring  performance  within 
acceptable  limits.  When  the  project  team’s  performance  is  stabilized  within  acceptable  limits, 
the  defined  software  acquisition  process,  the  associated  measurements,  and  the  acceptable 
performance  limits  are  baselined  to  permit  quantitative  control  of  the  project  team’s  performance. 

The  acquisition  organization  collects  performance  data  from  the  software  acquisition  projects  and 
uses  these  data  to  define  the  capability  of  its  standard  software  acquisition  process  (see  the 
Process  Definition  and  Maintenance  key  process  area).  The  capability  of  the  acquisition 
organization’s  standard  software  acquisition  process  is  indicative  of  the  performance  that  can  be 
expected  from  the  next  software  acquisition  project  undertaken.  These  capability  data  are,  in 
turn,  used  by  the  software  acquisition  project  teams  to  set  their  performance  objectives  and  to 
analyze  the  performance  of  their  defined  software  acquisition  processes.  The  capability  data  are 
also  used  by  the  project  teams  in  tailoring  the  acquisition  organization’s  standard  software 
acquisition  process  to  a  particular  acquisition. 
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The  goals  of  Quantitative  Process  Management  are: 

1 .  The  performance  of  each  project  is  quantitatively  measured,  managed,  and  controlled. 

2.  The  capability  of  the  acquisition  organization’s  standard  software  acquisition  process  is 
analyzed  and  defined  in  quantitative  terms. 

The  top-level  activities  performed  for  Quantitative  Process  Management  are: 

1.  The  acquisition  organization’s  software  acquisition  process  capability  baseline  is  defined  in 
quantitative  terms  and  is  maintained  according  to  a  written  procedure. 

2.  Each  project  team’s  quantitative  goals  and  objectives  are  derived  from  the  acquisition 
organization’s  quantitative  process  capability  baseline. 

3.  Each  project  team  performs  its  activities  in  accordance  with  its  documented  quantitative 
process  management  plans. 

4.  The  measurement  data  used  to  quantitatively  control  the  project’s  defined  software 
acquisition  process  are  collected  in  accordance  with  the  acquisition  organization’s  standard 
software  acquisition  process. 

5.  Each  project’s  defined  software  acquisition  process  is  analyzed  and  quantitatively  controlled 
according  to  the  project’s  quantitative  process  management  plans. 

6.  Causal  analysis  is  conducted  on  a  periodic  basis  to  determine  special  causes  of  variances 
from  the  project’s  defined  software  acquisition  quantitative  process  goals  and  objectives. 

7.  Changes  in  the  project’s  defined  software  acquisition  process  are  implemented  to  correct 
special  causes  of  variance. 

8.  Reports  documenting  the  results  of  the  project  team’s  quantitative  process  management 
activities  are  prepared  and  recorded  in  the  software  acquisition  organization’s  process 
repository. 
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Level  4:  Quantitative  Acquisition  Management 

The  purpose  of  Quantitative  Acquisition  Management  is  to  manage  the  contractual  effort  through 
the  application  of  quantitative  methods. 

Quantitative  Acquisition  Management  involves  utilizing  process  and  product  measurements  as  an 
intrinsic  part  of  management  review  and  oversight  to  quantitatively  manage  the  acquisition  of 
software  products  and  services. 

As  the  acquisition  organization  continues  to  attain  higher  levels  of  maturity  there  is  a  transition 
to  quantitative  methods.  This  transition  is  marked  by  the  involvement  of  all  levels  of  acquisition 
management.  The  result  represents  an  advance  from  contract  performance  management  to 
acquisition  management  using  quantitative  methods.  Another  result  of  this  transition  is  an 
expected  increase  in  the  quality  of  acquired  products  and  services. 

The  quantitative  acquisition  management  process  is  integrated  with  quantitative  process 
management.  The  actions  of  quantitative  process  management  at  the  project  level  and  across  the 
acquisition  organization  are  integral  to  acquisition  management. 
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The  goals  of  Quantitative  Acquisition  Management  are: 

1.  Quantitative  objectives  for  the  acquired  products  and  services  are  defined. 

2.  The  contracted  effort  is  managed  quantitatively. 

The  top-level  activities  performed  for  Quantitative  Acquisition  Management  are: 

1.  Each  project  team  performs  its  activities  in  accordance  with  its  documented  quantitative 
acquisition  management  plans. 

2.  The  quantitative  objectives  for  each  project’s  software  products  and  services  are  defined. 

3.  The  quantitative  objectives  for  each  project’s  products  and  services  are  incorporated  into  the 
solicitation  package  and  resulting  contract  according  to  the  project’s  defined  software 
acquisition  process. 

4.  Each  project’s  evolving  software  products  and  services  are  measured,  analyzed,  and  compared 
to  the  project’s  established  quantitative  objectives. 

5.  The  project  team  utilizes  quantitative  measurements  as  a  normal  part  of  management  review 
and  oversight  of  acquired  products  and  services. 

6.  Causal  analysis  is  conducted  on  a  periodic  basis  to  determine  special  causes  of  variances 
from  the  projects’  quantitative  objectives. 

7.  Changes  are  implemented  to  eliminate  special  causes  of  variance. 
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Level  5:  Continuous  Process  Improvement 

The  purpose  of  Continuous  Process  Improvement  is  to  evolve  the  software  acquisition  processes 
used  in  the  acquisition  organization  through  managed  continuous  process  improvement. 
Quantitative  objectives  for  the  acquisition  organization’s  standard  software  acquisition  process 
and  the  projects’  defined  software  acquisition  processes  are  the  targets  of  the  improvement 
activity. 

Continuous  Process  Improvement  involves  defining  quantitative  process  improvement  objectives 
with  the  involvement  and  sponsorship  of  acquisition  organization  management.  It  is  a 
continuous  effort  to  proactively  and  systematically  identify,  appraise,  and  implement 
improvements  to  the  acquisition  organization’s  standard  software  acquisition  process  and  the 
projects’  defined  software  acquisition  processes. 

The  commitment  to  continuous  process  improvement  is  acquisition  organization  wide.  Training 
and  incentive  programs  are  established  to  encourage  and  enable  all  acquisition  organization 
personnel  to  participate  in  the  software  acquisition  continuous  process  improvement  activities. 
Improvement  opportunities  are  identified  and  appraised  in  terms  of  how  well  they  move  the 
acquisition  organization  and  its  projects  toward  software  acquisition  continuous  process 
improvement  objectives. 

When  software  acquisition  process  improvements  are  approved  for  normal  practice,  the 
acquisition  organization’s  standard  software  acquisition  process  and  the  projects’  defined 
software  acquisition  processes  are  revised.  The  Process  Definition  and  Maintenance  key  process 
area  defines  the  actions  for  changing  the  acquisition  organization’s  standard  software  acquisition 
process.  The  Project  Performance  Management  key  process  area  defines  the  actions  for  changing 
the  projects’  defined  software  acquisition  processes. 

The  Acquisition  Innovation  Management  key  process  area  defines  the  actions  for  adopting  and 
transforming  new  techniques  and  technologies  into  the  acquisition  organization. 
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The  Goals  of  Continuous  Process  Improvement  are: 

1.  Participation  in  continuous  process  improvement  activities  is  acquisition  organization  wide. 

2.  The  acquisition  organization’s  standard  software  acquisition  process  and  the  projects’  defined 
software  acquisition  processes  are  improved  continuously. 

The  top-level  activities  performed  for  Continuous  Process  Improvement  are: 

1.  The  acquisition  organization  performs  its  activities  in  accordance  with  its  documented 
continuous  process  improvement  plans. 

2.  The  software  acquisition  process  group  coordinates  process  improvement  activities 
throughout  the  acquisition  organization  to  facilitate  organization-wide  participation. 

3.  Causal  analysis  is  conducted  on  a  periodic  basis  to  determine  common  causes  of  variances 
from  acquisition  organization’s  standard  software  acquisition  process. 

4.  Changes  in  the  acquisition  organization’s  standard  software  acquisition  process  are 
implemented  to  correct  common  causes  of  variance. 

5.  Appropriate  process  improvements  are  continuously  transferred  into  practice  according  to  a 
written  procedure. 

6.  Records  of  process  improvement  activities  are  maintained  in  the  acquisition  organization’s 
repository  for  software  acquisition  process  information. 
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Level  5:  Acquisition  Innovation  Management 

The  purpose  of  Acquisition  Innovation  Management  is  to  continually  improve  the  acquisition 
process  through  the  adoption  and  transfer  of  new  techniques  and  technologies.  Acquisition 
innovation  management  is  a  primary  responsibility  of  the  acquisition  organization;  however,  the 
adoption  activity  may  be  carried  out  through  individual  acquisition  projects.  While  a  project  can 
act  by  itself,  the  environment  for  adoption  should  be  fostered  and  led  by  the  acquisition 
organization. 

Acquisition  Innovation  Management  involves  the  identification,  appraisal,  implementation, 
adoption,  and  transfer  of  new  techniques  and  technologies  that  support  the  software  acquisition 
process. 

The  focus  is  on  improving  the  acquisition  process  through  the  adoption  and  implementation  of 
new  techniques  and  technologies.  Adoption  of  new  techniques  and  technologies  is  accomplished 
in  concert  with  continuous  process  improvement  (refer  to  the  Continuous  Process  Improvement 
key  process  area). 

Acquisition  innovation  management  of  new  techniques  and  technologies  encompasses  a  range  of 
possibilities.  These  techniques  and  technologies  are  those  which  are  new  on  the  horizon  or  are 
new  to  the  acquisition.  They  may  range  from  introduction  of  a  new  technique  to  the  project 
(such  as  automated  documentation)  to  adoption  of  a  new  management  strategy  (e.g.,  product  line) 
at  the  acquisition  organization  level.  The  acquisition  organization  and  the  project  act  in 
cooperation  to  implement  new  techniques  and  technologies  that  may  provide  a  specific  benefit  to 
the  project,  as  well  as  an  overall  benefit  to  the  organization. 
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The  goals  of  Acquisition  Innovation  Management  are: 

1 .  The  acquisition  organization  proactively  adopts  and  implements  new  techniques  and 
technologies  to  improve  the  standard  software  acquisition  process. 

2.  Participation  in  the  acquisition  innovation  management  process  is  organization  wide. 

The  top-level  activities  for  Acquisition  Innovation  Management  are: 

1.  The  acquisition  organization  and  each  project  perform  their  activities  according  to  their 
respective  documented  acquisition  innovation  management  plans. 

2.  The  group  responsible  for  conducting  acquisition  innovation  management  activities  conducts 
routine  and  periodic  appraisals  of  new  techniques  and  technologies  as  candidates  for 
inclusion  in  the  acquisition 

3.  The  group  responsible  for  conducting  acquisition  innovation  management  adapts,  pilots,  and 
includes  new  techniques  and  technologies  beneficial  to  the  acquisition  organization  into  the 
standard  software  acquisition  process. 

4.  Piloted  efforts  assigned  to  project  teams  are  performed  in  accordance  with  its  documented 
acquisition  innovation  management  plans. 

5.  The  acquisition  organization,  working  with  the  projects,  implements  activities  to  foster  an 
organization-wide  environment  that  facilitates  adoption  of  initiatives  beneficial  to  the 
acquisition  organization. 

6.  Software  acquisition  management  personnel  are  kept  informed  of  new  technologies. 
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Appendix  D;  Mapping  Features  to  Goals 

Since  satisfying  a  key  process  area  implies  addressing  each  of  the  goals  for  that  key 
process  area,  it  may  be  helpful  to  understand  the  relationships  between  the  common 
features  and  the  goals.  The  following  tables  map  each  common  feature  to  its  associated 
goal(s). 

Features,  like  key  process  areas,  are  not  independent  of  one  another.  Many  features  map 
to  more  than  one  goal.  For  example,  there  is  usually  only  one  policy  statement  per  key 
process  area,  and  it  covers  all  of  the  goals  for  that  key  process  area. 
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